Wednesday, December 2, 2009

Git: how to keep the master branch tidy, even if you've been working on it

In order to keep the master branch clean we want to avoid merges and "noisy" commits.

As you probably know, the best thing to do is to develop in a branch and rebase against master often (never rebase a remote branch). This ensures that your changes are always the latest changes applied to the index. And because they're applied on top of the index, when you merge them into the master branch and push, it's just a fast-forward update and you will never have to do a merge.

But what happens if you've been working on the master branch for a while? Is it too late? I just encountered this myself, and here's how you can keep the master merge-free in this situation.

On master

git fetch # have there been changes to master since you last fetched/pulled?  if not, you can just commit and push, otherwise...

git commit -a -m "awesome message here" # commit your changes
git branch wip           # create a new branch with your changes
git reset --hard HEAD~1  # reset the master branch to before your commit(s)
git checkout wip
continue working...
git fetch origin master
git rebase origin/master # rebase your changes on top of master often
all done...
git rebase -i origin/master # preferably squash your commits
git checkout master
git pull                 # make sure master has the latest code
git merge wip            # apply your fast-forward changes to the index
git push                 # quick before someone else does!

Can this process be shortened? Let me know if you have ideas.

Here are some excellent articles explaining some Git best-practices. There is some excellent info here, even from Linus himself!

Let me know if you have good Git articles. I'm still learning about Git, but now that I'm getting my head around it, it's getting better and better!

Karl

No comments: