Git/SCM Workflow: Handling changes when QA finds problems

Question

I'm trying to make the case for switching our organization to Git from SVN. Right now our workflow essentially looks like this:

1. Developer makes changes, then commits to Beta branch
2. QA finds bugs, then tells the dev to fix them
3. GOTO 1. Repeat at least 5 times. (We have no test suite. Another issue...)
4. Peer code review
5. 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.

Answer 1

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.