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.

Normally I don’t push my branch remotely until I’m ready for code review, but some times I may push it early if there are parts that may be beneficial to others or parts that I need to discuss.

Okay, so work is complete, I push it to GitHub and make a pull request. Next I start working on something new, so I create a new branch based on develop. Except, if the new task depends on the task I just did, the new branch will be based on my previous branch.

Not so fast… code review inc!⌗

Normally I have at least one pull request in progress while working on a new task. Git helps me being flexible here, so that I can easily switch branches to fix my code based on code review comments. The changes are force pushed, and I can then continue on my current branch and task.

Since I’m not appending commits, but rebasing and updating my commits (as this serie on How I Git it has been all about), I’d like to point out one great feature of GitHub that supports this way of working.

Whenever someone force push a branch I can see that in the Pull Request in GitHub like this:

Link in GitHub PR showing I’ve force-pushed to the branch

Clicking the “force-pushed” link, I can see a diff between the whole branch before and after the force push. That’s great when I’m reviewing a pull request, because I can verify that all of my comments were addressed and I can see how my team member changed the code.

If it were not for that feature, I can see how some people is concerned with updating commits instead of appending “fixes”. In fact, back in 2014 GitHub didn’t have that feature. Still we believed in updating commits, and we solved this issue by making sure the developer left a summary of changes made after a force push. I think that’s good practice today as well in any case.

Context switching⌗

Since I am usually juggling one or two pull requests and a new task, and also doing code review on other team member’s pull requests, there may be a lot of context switching throughout the day. Of course that is not ideal for focus and productivity, but also it’s not really avoidable unless:

  • I am not working in a team.
  • I don’t care about what my team members are doing.
  • I don’t want (or allow) feedback from my team.
  • I don’t make mistakes so I don’t have to go back and fix them.

Since the above isn’t true for me, I try to see and recognize the importance of the quality improvement and learning opportunities that I get from this, even though I think it’s only human wanting to move on and focus on the new task. New things are more fun after all! (I didn’t bother editing and proof-reading my essays in high school and my grades definitely suffered from that).

Being able to switch code in and out and making changes in a way that keeps me sane (linear history and logically atomic commits) is essential to managing it all. Git, with rebase in particular, is the tool that makes it relatively easy.

Final words⌗

Don’t get me wrong. I don’t like merge conflicts. I don’t really enjoy fiddling with git and rebase and being all neat about it. In fact I put a lot of effort into avoiding the more time consuming stuff. What I find helps the most is to create logically atomic commits. Also, it’s much easier to commit often and move and/or squash later. Splitting commits are harder. Sure it takes some time to be thinking about these things when developing, instead of purely focusing on code and the solution. But I believe it’s worth it for me, my team and my company.

If you made it through to the end: thanks for reading!

I’m thinking maybe my next post will be about another touchy subject: nitpicking!