Git tips

In this post, I would like to explain some tips on successful git workflow.

Feature branches

Feature branches is very common and I think one of most important concepts of successful git workflow. Before you start working on new feature, create a new branch for it based on latest master. Then commit all work into this feature branch. If master changes and feature branch gets outdated, rebase it to current master (it is safe to do so with your private branch, but be careful when working with shared branches). BUT NEVER MERGE current master into it. It will mess git history and it is absolutely not necessary to do that.

Single purpose commit

I believe every commit in git should have single (and clear) purpose and should leave code in stable state. I must confess I’m still strugling with achieving that, but I believe it should be ultimate goal and would improve git experience. In case of regression, it would simplify finding out which commit broke the code and also simplify fixing it. (In worst case reverting the commit, in other cases creating bugfix commit).

It might sound like like clear and very obvious thing, but it is not. I have seen (and done) many commits with multiple unrelated changes. Sometimes I still do it, but I’m trying to get better and stop. Recently I learned git add -p which helps with that - instead of staging whole file it shows dialog where you can pick which changes you want to commit.

Descriptive commit message

I think git commit messages are quite often underestimated. They should be as descriptive as possible. Sometimes it is good to explain details in longer sentences or even few paragraphs. In each case, it is good to keep commit title at max. 50 characters and describe details in body.

Interactive rebase

I got used to commit often workflow, so my feature branches usually contain tens of very small commits. Before preparing final PR, I use git rebase -i and squash related changes into single commit. I’m trying to follow previously described Single purpose commit rule and also keep code in stable state after each commit.

git clean -i

Sometimes in happens you have multiple unversioned files in your working directory and you want to get rid of them. But you don’t want to delete all of them, only some. For that, there is a great git clean -i command. It allows you to filter out files, which you want to keep.

git format-patch

git format-patch is another great git command. You can create patch file by using git format-patch master...your-branch (or any other commit refs). It will create patch file, which can be applied by git apply. (But you could also use ani native tool to work with patches).

I used this command when I had to port single changes from my git repository into separated SVN repository.

git push –force-with-lease

There is one caveat when you need to push rebased branch. Git won’t let you do that and warn you about remote changes you don’t have locally. This happens usually beacause rebase changed branch history and you have to use --force to convince git to allow you to push into remote repository.

But there could truly be some new changes you don’t have locally and git push --force would override them.

You can use git push --force-with-lease command which is kind of --force with seatbelts. It will allow you to override remote branch, unless there really are some changes you don’t have locally.

You can see more explanation about how git push --force and git push --force-with-lease works in this blog post: https://developer.atlassian.com/blog/2015/04/force-with-lease/