Mark Needham

Thoughts on Software Development

Git/Mercurial: Pushing regularly

with 4 comments

I was reading a recent blog post by Gabriel Schenker where he discusses how his team is making use of Git and about half way through he says the following:

When using Git as your SCM it is normal to work for quite a while – maybe for a couple of days – in a local branch and without ever pushing the changes to the origin. Usually we only push when a feature is done or a defect is completely resolved.

We’ve been using Mercurial on the project I’m currently working on over the past few months and although it’s a similar tool we’ve been following a different approach.

We’ve got it setup the same way we would setup Subversion:


We’ve been trying to push to the central repository as frequently as possible, just as we would if we were using Subversion.

I don’t know the Git workflow that well because I haven’t used it on a project yet but we’ve always found that it’s beneficial to integrate with code being written by others on the team as frequently as possible.

Not doing this can lead to the problems which Martin Fowler outlines in his post about feature branches.

We’ve tried to ensure that after every commit the build still passes although we do sometimes have broken versions in the code committed locally because we don’t run our full test suite before every local check in.

Even if a feature isn’t completed I still think it’s valuable to have what we’ve done so far checked in and it also helps remove the problem with needing to backup local repositories:

Since we are going to work locally potentially for days without pushing to the origin (our central repository) we might well loose our work if we have a hard disk crash or our office is flooded. Thus we need some backup strategy.

We just need to make sure the central repository is being backed up and then the danger of losing our work is significantly reduced.

Be Sociable, Share!

Written by Mark Needham

June 19th, 2010 at 10:14 pm

Posted in Version Control

Tagged with ,

  • I don’t know the Git workflow that well

    Part of the beauty of git is its flexibility, so there isn’t really “a” git workflow.

    We tend to push often too, but if for some reason someone’s working on something that can’t be merged straight away, they create a short-lived feature branch, and push that frequently instead. That way there’s still a central copy of the work in progress, and multiple developers/pairs can collaborate on the branch if necessary.

    We just need to make sure the central repository is being backed up and then the danger of losing our work is significantly reduced.

    Of course another advantage of using a DVCS is that the central repository is backed up – to each developer’s machine (and likely your CI server too).

  • I find myself commiting locally very often indeed – but pushing to the canonical source as often as before. I would question why even short-lived feature branches are needed – they often highlight a missing abstraction in the code.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #625()

  • Pingback: Tweets that mention Git/Mercurial: Pushing regularly at Mark Needham --