Whenever I read about Scrum and how it should work, specific functionality should be finished and considered shippable at the end of a sprint. And that stories burndown throughout the sprint.
I wonder what the proper Git is set up to make this happen?
We currently have feature-based branching for our development work. A developer cuts a feature branch from the dev branch, works on it, and merges it back to the dev branch. Should the updated dev branch code then be pushed to the QA branch to test? Or is it wise to let the other features being worked merge back to dev then push everything to QA? I am asking because we are in a situation where nothing finishes until the last day of our sprints, and it would be nice to see stories close throughout the sprint.
The approach you take will depend on a number of factors:
The ideal approach is to have ongoing work commit to your main branch. The way this is achieved is to have a lot of good continuous integration and automated test coverage. This gives you the confidence that any code committed to the main branch will not have impacted on existing features.
If you use feature toggles and selective releases then this further de-risks the approach of merging everything into the main branch.
This is the approach that teams frequently use when they want to have continuous delivery.
If you have a manual testing approach or limited automated test coverage then merging code to the main branch is a risky approach. Instead you might look to work in feature branches. However, it is possible to reduce the risk of merge conflicts by frequently merging from the main branch into your feature branches. That way, as features are brought back together the problems have mostly been resolved already. I would suggest doing this frequent merging using continuous integration tools.
Using the above approach will help, but it will still be difficult to complete features progressively through the sprint. To achieve this you will likely need to start investing in more automated regression test coverage and by generally raising quality standards (perhaps by using a test driven development approach).