It depends on the nature of the user stories.
It can be effective to create a branch for each user story, progress on different stories are visible, they can be passed around if needs be, if stories aren't completed in the sprint then the progress can stay in the branch for the next sprint. Final reviews can then be performed at the end of a user story in the use story branch and merged in if the code is up to standard.
To work in the manner stories need to be finely grained to prevent unmanagable merge tasks at the end of a sprint. Small stories will allow a steady update of the dev branch through the sprint that devs working on other user stories need to constantly pull from (basic VCM).
This does create process overheads having to create and merge branches constantly which in some cases can be resolved with automation scripts but the team still needs to be very comfortable with the VCS.
At the end of a sprint you merge your dev branch into integration/production etc.
I have also worked in teams where everyone works off one dev branch, on completion of a user story the code is pushed to that branch for review and testing and if someone pushes something that breaks the dev build they have to get the team beers in.