5

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.

Luke The Obscure
  • 1,524
  • 2
  • 20
  • 35

3 Answers3

3

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.

Community
  • 1
  • 1
Adam Spiers
  • 17,397
  • 5
  • 46
  • 65
  • 2
    +1, great answer. I'm curious though why you suggest avoiding the *git-flow* approach, but advocate history rewriting (which is not only complicated but can be rather dangerous). I've used *git-flow* (albeit without the actual extensions, just pure Git) in many projects with both myself as a lone developer and in teams without incident. – Justin ᚅᚔᚈᚄᚒᚔ Aug 09 '12 at 22:45
  • 1
    Looks like our comments crossed mid-air :-) *git-flow* certainly can work, even in lone developer scenarios like you say, but the OP specifically asked for something which isn't going to increase the resistance to change. I know from experience that persuading people to switch to even very basic usage of git can be a painful process, so as soon as you start drawing branch graphs, they'll run away screaming. Secondly, I strongly believe that the FUD about the dangers of history rewriting should not be spread, because git's history rewriting features are a *huge* advantage when used properly. – Adam Spiers Aug 09 '12 at 22:48
  • 1
    I agree about resistance to change, but in order for a switch to Git to be even remotely useful requires that the people using the tools understand **why** it's different and better. If all you're doing is saying "use `git commit` instead of `svn commit`", then why bother with the transition? I also agree that history rewriting is powerful and I'm not trying to be a FUDdy-duddy, but that caveat **when used properly** is important. It's easy to shoot yourself in the foot/leg/crotch if you don't know what you're doing, and as such probably isn't something that belongs in a 'simple' workflow. – Justin ᚅᚔᚈᚄᚒᚔ Aug 09 '12 at 22:56
  • Of course, but there are many other [good reasons for using git](http://git-scm.com/about/) aside from the ability to use *git-flow*-like models. And if you re-read the 3rd paragraph of my original answer, you'll see that I already included a strong caveat, and also evaluated whether rewriting is safe in his described scenario. – Adam Spiers Aug 09 '12 at 23:11
2

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:

  1. Developer makes changes and commits to their feature-X or bugfix-Y branch.
  2. Developer merges feature or bugfix into develop and pushes to the server.
  3. QA finds bugs, files a bug report.
  4. GOTO 1. Repeat X times.
  5. 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.
  6. At the end of the sprint, branch manager merges all code from develop into release-candidate for QA to do any final validation, or directly into master if 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.

Justin ᚅᚔᚈᚄᚒᚔ
  • 15,081
  • 7
  • 52
  • 64
  • Given that he specifically asked for a simple workflow, I suspect the nvie model is way too complex for his scenario - as I already mentioned, even github find it too heavyweight. I think it only makes sense for really big projects which have large numbers of concurrent streams of development ([OpenStack uses it](http://wiki.openstack.org/BranchModel), for instance). – Adam Spiers Aug 09 '12 at 22:44
  • @AdamSpiers: Looks like we replied to each other at the same time. I find it difficult to understand how you can say the *git-flow* model is too complex but advise history rewriting in the same breath. To me, it's much more complicated to try and reverse-engineer your commit history than it is to just keep things separate until they're finished. – Justin ᚅᚔᚈᚄᚒᚔ Aug 09 '12 at 22:48
  • I'm not advocating any reverse-engineering, and I *am* saying things can be kept separate during development. But I wouldn't consider a feature branch *finished* if the history is a complete mess, and that applies especially in the scenario above, where the OP describes the current peer review of the unpolished history as "really difficult". – Adam Spiers Aug 09 '12 at 22:53
1

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 Beta branch 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 dev branch...other developers can be pushing development code there
  • When Beta is good to do, merge it into master and dev.
  • For the next release, cut a new Beta branch from your dev branch 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 n.

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. :>)

brianz
  • 7,268
  • 4
  • 37
  • 44