Git/SCM Workflow: Handling changes when QA finds problems
I’m trying to make the case for switching our organization to Git from SVN. Right now our workflow essentially looks like this:
- Developer makes changes, then commits to Beta branch
- QA finds bugs, then tells the dev to fix them
- GOTO 1. Repeat at least 5 times. (We have no test suite. Another issue…)
- Peer code review
- At the end of the sprint, branch manager merges all code that’s marked as ready into the master branch.
I see Git as potentially helping a lot with steps 4 and 5. Specifically, the peer code review is really difficult when there’s 10 commits, with potentially lots of commits in between*. I know with Git it’s easy to revert commits, potentially creating one commit per feature/bug to review. Leading me to my question:
What is the best Git workflow for a scenario involving a lengthy QA back and forth?
Keep in mind that I’m encountering some resistance to change, so the simpler the workflow the more likely it is to be adopted. Also keep in mind that this is a Web Dev project, so QA tests against a Beta server, not locally, so QA switching branches isn’t really an option.
*Meaning, there may be commits from other bug tickets on the same file in between commits for this bug ticket, making a simple comparison to the previous state and isolating code changes for this ticket only difficult.
3 Solutions collect form web for “Git/SCM Workflow: Handling changes when QA finds problems”
Your question would be easier to answer if you listed more specific goals for the workflow. It also strikes me as odd that you are involving QA before peer code review, when best practices advise the opposite.
However, from your reference to reverting commits, it sounds like one of your main goals is to avoid a dirty history, which is full of commits entitled things like “oops, QA just pointed out I screwed up the last commit, this one fixes it”. If so, you should familiarise yourself with git’s powerful history rewriting capabilities – in particular squashing, splitting, reordering, dropping commits via
git rebase -i. These can be used to produce a clean, concise set of commits for each new feature or bugfix, making peer review and all future re-reads of the history much easier. I won’t go into details of how to do this, because it’s covered in countless other places.
You should also be strongly aware of when it is safe to rebase (typically only in “private” branches) and unsafe (“public”) branches, and of the implications of breaking that rule of thumb. However, in the scenario you describe it sounds like QA are not involved in the setup of the repository used by the beta server, in which case it’s probably safe.
Secondly, you should ensure that you always have one branch per feature or bugfix. This will drastically reduce the difficulties which you currently face when peer reviewing and merging, because each set of logically related changes will be cleanly isolated, rather than intermingled with unrelated changes – the latter scenario will confuse and destabilize the review and QA processes. There are much more sophisticated git branching workflows out there which some people love, but it sounds like you should avoid those for now if you are worried about scaring your co-workers away from a migration to git. Even an organization as big and sophisticated as github prefers a simpler workflow.
Every time I see a post about workflow with Git, I can’t help but refer them to Vincent Driessen’s excellent writeup A successful Git branching model. The first time I read this, a lightbulb went off and I realized that this approach can be the basis for nearly any project.
Since yours is a web development project, simply have your QA server pull the
develop branch (or if you have a Dev server separate from QA, from a
qa branch that pulls from
develop). Your revised workflow would be thus:
- Developer makes changes and commits to their
- Developer merges feature or bugfix into
developand pushes to the server.
- QA finds bugs, files a bug report.
- GOTO 1. Repeat X times.
- Peer reviews can atomically review the changes that involve a specific feature and approve/revise/reject it, since each feature’s merge commit specifies all of the changes for that feature.
- At the end of the sprint, branch manager merges all code from
release-candidatefor QA to do any final validation, or directly into
masterif there’s no need for a special release branch.
As you can see, it’s possible to adjust the approach to meet your specific needs. The workflow is relatively simple, though your devs will need to get used to the idea of working in feature/bugfix branches and merging when they’re finished.
I moved my company from SVN to Git, learning lots about Git in the process. Since that move, I’ve seen our workflow develop and change over ~3 years…based on that, and also based on using Git in my own personal shared projects:
The nvie model is great. I use it for my own projects where there are only 2-3 people and love it. However, there’s no way I’d suggest it for a larger team unless everyone committing code were advanced Git users. It places a lot of responsibility on people cutting branches from the right place, merging into the right places and generally “doing the right thing”. In reality, with a large team there will be several people who won’t understand Git, memorize a few commands and finally throw a wrench in the whole plan. If you’re getting resistance to change now, this will only make it worse when it blows up (and it will).
From your description (with your current, or lack of, software practices), one way Git will make your life easier is by isolating your
Beta branch from other development branches. So, you would:
- Cut a
Betabranch from master
- Do work. Git will not save you from developers being sloppy and pushing untested/unreviewed code. However, it will allow developers a chance to correct any mistakes they’ve made and noticed before they’ve pushed their code (rebasing, or amending commits)
- Assume you have a
devbranch…other developers can be pushing development code there
Betais good to do, merge it into
- For the next release, cut a new
Betabranch from your
devbranch and repeat.
So, you haven’t slowed anyone down since folks can always commit into
dev. You also have a release candidate (
Beta) branch which is only getting bug fixes.
Git can also help here because you don’t necessarily need to push your code before doing a code review. We use Review Board and the way that works, you commit your code locally and post a review. When you get feedback, you can simply update your code,
git commit --amend and update your review. When it’s all done, we push one commit rather than
From your description it sounds like unit tests and more responsibility for quality code from your developers are a better investment right now. By itself, Git won’t solve your problems, but it can at least help. You’ll have a lot more options on how to setup your development process using a DVCS like Git. And let’s face it…Git is just way more fun to use than Subversion. :>)