A Blog by Ian Monroe

It's been a while since I blogged last. I blame microblogging. So just to introduce myself again, I'm Ian Monroe and I'm an Amarok developer. I live in Iowa, USA. For about a year and a quarter I've been working for Collabora. I believe the rate of hired Qt developers has been growing exponentially at Collabora year-to-year since 07, so it won't be long until we all work for them. ;)

You'll find tons of sample Git workflows in Git docs all over the Internet. We've been using Git in Amarok since July and I've been using it everyday at my work since January so now I have my own Git workflow to add. It assumes you know the basics of Git already and that the project you work on is actively developed by others at the same time.

But first a note on why my commands are longer...

Keep it Explicit

One thing that much of the documentation for Git does is make things 'simple' by using various command shorthands. From helping fellow Amarok devs get used to Git and just from my own experience I've decided that in the longterm using commands that combine several tasks or use default options are confusing. Most of us type at about 50 words per minute causally, there's really no reason to skimp.

An example of this is to use git push origin master:master instead of git push. That tells you exactly where your commit is headed: to the default remote named origin. The master:master says you are pushing from the local branch master to the remote branch named master. I like being explicit with branch names since getting mixed up which one you have checked out is a mistake I've made before.

Importantly it keeps you in control and aware of what you're doing.

A Workflow

So you notice it's time to go make dinner, instead of just leaving the code uncommitted I say its a good idea to go ahead and do a git commit -a before you leave. Writing the commit log is helpful for when you sit back down later. Remember you can always git commit --amend and add to your last commit before pushing.

Okay so next morning, back to hacking. Time to update. It is important to often update to avoid conflicts.git remote updateThis command refreshes all the remote branches. It doesn't touch your checkout. Both 'pull' and 'rebase' let you interact with remote branches directly, but I like to break it up. So now bring in the latest changes to your checkout:git rebase origin/masterThis is mostly why I like to leave all changes committed before I leave, because then the rebase works without you having to remember to git stash or commit when you're updating in the morning before having had any tea.

The advantage of rebase over doing a merge/pull is that it changes the commits you haven't pushed yet by making them patches on top of the latest code. It gives those commits a 'new base.' It's actually how Subversion works all the time, if that makes it easier to understand. This leads to easier to understand linear history, in the unlikely event everyone else in your project also uses rebase.

Okay now you've done more hacking and are ready to push. Repeat the above steps to make sure your code is still up-to-date. If you try to push when its not, Git will notoriously tell you that you are trying to do a non-fast-forward. It sounds scary, but 90% of the time it means you just need to update.git status
git commit -a #or git commit -a --amend if you want to add to a current commit
git remote update
git rebase origin/master
#maybe double check it still compiles after updating
git push origin master:master

Obviously there are other ways to use Git, but this is mine. I hope it has been helpful.