Our master branch was following a squash-merge strategy, which meant that pull requests would eventually get into master and have all their changes squashed into one commit. This works fine, but had some disadvantages as well. Especially when more than one thing happened in a PR, things were getting a bit problematic.

So we decided to retain detail in our branches and let those ‘side-tracks’ stay in our repository. It takes a bit getting used to, having a git repository that looks like your average railroad yard…

It’s not that bad though, once you get the hang of it. And there’s some bonus to it, you can more easily track who did what. (Over here responsibility of a PR doesn’t rely with the developer who made it or the one who approved it, but with the entire team, so we’re not pointing fingers here.) But detail gives in some cases more insight and that’s valuable.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.