Alex E. Fish

iOS Developer in London, rambling about Objective-C, iOS Development and anything related.

If you would like to get in touch, feel free to email me or @ me on twitter.

Don't be a dick, with git

I remember a world before git, it was a horrible place, I stumbled across this talk from Linus Torvalds at Google in 2007 which reminded me just how bad things were before git. This post isn't about how great git is though, this is about how you could be ruining git for everyone else.

I'm going to brush over a few areas of possible git dickery and in my opinion what you can do to avoid being that guy or girl that everyone is whispering about in the shadows.


It would be easy to write a whole post just about branching but I'll keep things brief.


Use a branch naming convention that is consistent across your repository, if it's someone else repository, stick to their naming convention for branches. Personally I enjoy how git-flow handles things but use whatever works for you.


This makes it very easy when switching between branches, looking at the history or merging for anybody to get a quick idea of what's going where.

Not branching

Never commit directly to develop/master, this is a classic git dick move. Doing this side steps any code review or ci build safety checks you should have in place. Thus hugely increasing the chance of commiting broken code and breaking everything for everybody else when they pull down from remote. Make a branch for your feature/fix and get somebody else to merge it back into the mainstream when you think it's ready.


It's very easy to be a dick when commiting code, here are a couple of things to avoid.

Big commits

Everybody hates the team member who works on a feature for 4 days without commiting a thing then pushes up their changes in one giant mega commit. This mega commit is a nightmare to review and revert if shit hits the fan. Commit often and commit in a modular way using patches:

git commit -p

This command allows you to break up your work into meaningful chunks that are easy to revert and cherry-pick if needs be. There is also its bigger brother git commit -i, personally though i think git commit -p does everything you need.

Commit messages

Just as useless as doing giant commits is giving commits useless messages, imagine trying to figure out what does what when your log looks like this:

    * commiting changes
    * updates
    * fix
    * fixed broken thing

Don't be that person! Write a short summary that sums up your changes nicely, then hit enter a few times and write a decent description of what you did. Follow these guidelines to avoid git dick status.


Rebase is your friend, merge commits are your enemy.

Merge commits

My number one pet peeve when working on a branch alongside other developers is people who don't pull with rebase. Not rebasing creates pointless merge commits like merging feature-1 into feature-1. No one needs that in their history, it's completely useless, by pulling with rebase your changes are in one pretty line of history as they should be in the order they should be.

git config --global branch.autosetuprebase always

Use the above command to pull with rebase by default and save yourself having to remember the rebase flag every time you pull on your branch.


TODOs are useful when working on a fix or feature to remind yourself of what needs to be done, they are also useful if you want to be a dick.

Remove TODOs

By leaving TODOs in the code base you are letting everybody else know you are lazy and want someone else to deal with it. Remove your TODOs and do them before you request to merge back in from your feature or fix branch. Nobody likes working on code with a ton of TODOs all over the place because the last developer was too lazy to actually DO the TODO.


Just as with TODOs, logs are very useful while working away to debug, they are also useful for clogging up the console and codebase.

Commiting logs

This one is simple, don't commit logs, or if you do, remove them before you need to merge your feature of fix back into the mainstream. Leaving logs all over the place clutters up the codebase and is generally annoying when another developer is trying to debug something with their own logs.

There is also the matter of security, leaving logs in your codebase could open up some security holes giving the bad guys an insight into how your application works or worse, user details like Starbucks did.

Pull requests

Pull requests are a powerful workflow to use as a safety barrier between your mainline codebase and feature/fix branches. As with everything else though they also provide another opportunity for being a dick.

Titles and descriptions

On a similar note to writing meaningful commit messages writing good pull requests can save your team some headaches. There is nothing worse then going to review a pull request and finding there is no description and a very brief meaningless title.

Save your fellow developers some pain by being a good contributor, airbnb have a handy bookmarklet for opening good pull requests easily.

And that's it, follow these simple steps to be everybody's favorite git buddy instead of everybody's worst nightmare. Let me know if I've missed anything.