Small steps with big feet

The last months, I’ve been quite heavily using Git. After the initial hurdles, swearing and cursing, I fell in love with it and switching back to Svn is now a pain.

Git is extremely powerful and flexible, and this is exactly the major cause of headaches in the beginning to get your ‘flow’ as you want it. I read a lot of people’s blogs documenting their git workflow, and came to my ‘own’ workflow (which is hugely based on a very excellent blogpost which I can’t seem to find anymore now), which I wrote on a piece of paper lying on my desk. As that paper is getting more coffee-stains by the day, I finally decided to write my flow down here – more for my own documentation purposes than anything else. And hey, maybe somebody might find this useful.

If you are starting out with Git, get a Github account. Github is simply brilliant.

I’m using command-line only, but other people on the team are quite happy with Egit. For me, it magicfies things too much. The following steps asume that you have already initialized your local and remote Git repo. If not, just create a new Git repo on Github and follow the instructions there.

First of all, make sure your local copy is to date with the remote repo:

git pull

This git ‘pull’ takes all changes from the remote master branch, and applies it to your local copy. I like to keep my local master branch clean, and exactly in sync with the remote master. This way, I always have a stable version of what I’m working on. Also, if other people push stuff to master, I can easily pull it in and see what changes without having to merge to see what they did. This said, I create a branch for doing my actual work. This can be a general ‘dev’ branch or a branch for a specific feature implementation:

git checkout -b cool_feature

This creates a new branch called ‘cool_feature’ and switches to it. All changes I now to, are done in this branch. Regular, I commit stuff to my local repo

git add .

git commit -m “implemented part 1 of the cool feature”

The ‘add’ command, allows to specify which files you want to prepare for the commit. 99% of the time, I just add the dot, meaning every change should go in the commit. Often, I also use the ‘- -amend’ flag, to merge this commit with the last commit. Otherwise, you’ll have a lot of smaller commits (which is also good, but I don’t like it).

When I feel that my work is complete and all is working dandy and fine, I need to push it to the remote master branch so that the other teammembers can see its awesomeness. To do this, you need to switch to the master branch, and pull any incoming changes (this always works, as I don’t do any changes on master). Then, switch back to the branch, and merge these changes using a ‘rebase’ (this makes the commit history lineary, which is nice).

git checkout master

git pull

git checkout cool_feature

git rebase master

Potentially, merge conflicts now arise. You can resolve these in text-mode in the files itself, but I like a graphical merge tool more. I’m using p4merge for this purpose, and I’m really happy with it. To resolve merge conflicts, execute

git mergetool

Now it is time to merge your branch with the local master branch, and push the changes to the remote master.

git checkout master

git merge cool_feature

git push

And that’s it!

Imo, still one thing needs to be optimized in my flow: I don’t like to have many local commits which are not on a central repo. You never know when my laptop might burn out. To solve this,  need to push my local branches to as remote branches to Github. But I still need to make that a habit and I tend to forget it.