A while ago a few posts on the subject were posted github’s workflow and how github works and I hope you’ve already read those. But now it’s time to convince more people who are still “on the other side” to make this your missing new years resolution for 2012!

Peoples perspective before they switch to Git

Arguments I heard for not switching:

  • Git is hard and you’ve got to be insane to understand
  • Teams can’t be in sync (or work together) when they work with a
    distributed model like Git.
  • I would never put my code on github, I don’t trust them with our business
  • Git is popular with hipsters who code ruby (see github)

Making the jump

If you have experience with other version control systems like SVN or even CVS, it’s likely you’ll be influenced with this when learning Git. I’d like to share my ideas in the hope it will disrupt some assumptions.

Git is not attached to a server and has nothing to do with cloud.

cd /my-new-project git init
echo "I have a new idea and want to keep
track of my code" > README
git add README
git commit -m "initial commit"

There! Start using Git and you’ll see there is no connection required! Wonderful because I can create and switch branches, commit the work I have completed. When it’s worth sharing (with a team, your boss or with friends) you can publish everything and continue.
This is one detail but it might add to your imagination about the distributed model.

Git is too complicated I just want to commit to the server

SVN its centralized SCM (source control model) might be familiar and wanted in your project. Keeping a straight commit history (without merged branches etc.) can be done in Git too. But why switch would you ask. I say there is something more going on.

The culture (consistent behaviour) I see with SVN users is typical: large commits, reverting a commit is not practical and last and unsurprising: merging a branch is awful and thus avoided most of the time.
Those repositories end up with what I call a dirty commit history.

With Git (and lets include Mercurial too in this) technical advantages create the opposite behaviour:

  • commits are stored local (always faster) encouraging you making smaller / frequent commits
  • so called “oops commits” can be avoided because local commits can be edited (git commit –amend or git reset HEAD^)
  • control over the source is optimal when you keep commits small and focused on the task (this is true in SVN too)
  • reverting is easy as looking up revision
  • branches are cheap (you hear this allot)

The reality

Hosting git yourselves is not the problem. But still github gives so much advantages over the alternative. And this way the focus remains on our technical challenges instead of the communication challenge which comes with the distributed model.

So we use github, and this is our workflow in a nutshell:

  1. A repository gets created and we call it ”upstream”
  2. Each team has a few people allowed to merge pull requests: The merger (I could write a whole article about those guys)
  3. Every team member creates a fork we call it ”origin” git remote add origin git@github.com:username/yourfork.git
  4. Developers make changes in a new branch, push this to their fork and create a pull request
  5. The merger does a tiny code review but sometimes clarification is needed.
    • this way someone else does not have to fix your mistakes
    • and your code is understandable.
  6. The merger… merges your pull request
  7. Get some coffee, you’re fellow developers can run: ”git pull upstream develop” to get in sync

We take some extra effort to run backups every hour to all our repositories is down.
And when this is needed developers add an extra remote ”backup” and they can stick to the work flow as described. Just in case.

End notes

Our switch to a distributed workflow was experimental at first and has taught us allot when we look back on it. We see teams are not forced to communicate directly anymore but can work asynchronous and communicate more via IRC or email. And this gives developers more time span to concentrate (less interruptions). Another thing is that the methods feel very aligned with our take on agile development. Example: it’s trivial to make release branches per sprint or release, do a hotfix on the release branch and let the rest of the team work in develop etc.

And even though there are situations where communication lanes get very tight and almost synchronous. This can be when we get close to a deadline. Those are the times when the phrase: “see my pull request” becomes the new “svn up please” and this makes us smile, because you know someone is in control over what gets merged (and what isn’t good enough).
So in the end we are very content with the impact on our switch and I’d like to hear about your experiences.

Showing 2 comments
  • Stefan

    I *love* Github and promote it at every turn, but it might be wise to also mention other services, such as the wonderful Bitbucket.org, which is also worth a try.

    • Marc Stalfoort

      Good point Stefan. Is Github ‘the holy grail’?
      I recently did make an account at bitbucket but haven’t used it though. It could make a nice follow-up once I find the time to play with it, or someone else of course 😉

Leave a Comment