If you read my previous series on How I Git it, you know I like my git commits all nice and clean. I do this for you, my dear code reviewer. I remove the noise so that you can focus on the change. What is the purpose with code review, if you cannot see through the noise?

This is part 5 of my serie on How I Git it. You can read Part 4 here. Work complete, next please It might be clear already, but just to state it, I always work on my own private branch. I expect no one to depend on it being in a certain way, because I will force push all sorts of changes to it. A commit that was there yesterday might very well be gone today.

Pulling in new commits from another branch and solving merge conflicts like they never happened!

Rebase rebase rebase…

Rebase is such a great tool to get my commits just right. Basically, it’s this process that let’s me rewind back to a commit of my choosing, and then replay all the commits, one at a time, allowing me to:

I’ve been working as a software developer since 2008. In 2014 I was lucky enough to get involved with a team who used Git in a way that really made sense to me. It made collaboration easy and improved overall quality of both product and developers.