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 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.