Rebasing a PR train does not have to be a pain

#git

This one will probably be obvious for most of the readers, but I got this lightbulb 💡 moment only just a week ago.

A Pull Request (PR) train is when you create a PR that is dependent on another PR, that is dependent on another PR ... and so on. Therefore first "carriage" of the PR train points to master, second carriage points to first carriage, third points to second, etc.

This method of chopping work into smaller pieces has a great benefit that the diff of each Pull Request can be very small and therefore should be easy to review.

The problem of this approach is that if you need to change one of the earlier carriages (for example because of a feedback on your PR), then all the later carriages might have a merge conflict. Similar can happen if you just need to rebase your whole PR train on the latest master.

The aha! moment

Until last week I was struggling with this because during the rebase of each individual carriage I had to resolve it's own conflicts and the conflicts of all the carriages before.

The problem was that I was simply doing a normal rebase, which takes all the commits from the current carriage and all the carriages before. So I needed to resolve the same conflicts over and over again:

One of the methods of how one can improve the rebasing situation is to realise that: "each carriage cars only about it's own commits". Not the commits of the carriage(s) before. Those are not important and can be dropped.

This can be done via an interactive rebase:

And simply by selecting drop for the commits that are not relevant:

And that's it.

Conclusion

By dropping the commits during a rebase that are not relevant in our current PR, we are making our life easier by making sure that the same merge conflicts have to be resolved only once.

Photo by Jack Anstey on Unsplash