Here at StartupLandia, we work with legacy codebases and new ones. And while starting clean gives a lot of freedom, we all know it comes with responsability. Today we’re going to talk again about our favourite git setup and how to not lose ourselves in the merge conflicts while shipping that $1M feature.

Here’s a visualisation on the topic I would like to talk about!

On the left you can see the git log of the jsonapi-serializer and on the right is the log of the jsonapi.rb codebases.

The left hand-side log is a result of merges caused by multiple pull-requests. And while multiple pull-requests are a normal thing in highly efficient teams (like ours 🤓), the summit of so called branch commits that got merged on top of the each other, is something that can and should be avoided, and not just for visual aestetics.

The nested git log full of merge commits is not only harder to track, but also makes it hard to revert a specific commit, or identify a commit when trying to run git-bisect.

Introducing other ways to git merge

Fast-forward merges are another way to merge pull-requests. Merging branches with the git merge --ff will leave a cleaner log and also force the author to potentially rebase the local chanes avoiding an upcoming merge conflict. And we all know, less conflicts, means happier life and more time for that beauty sleep :smiley:

But ser, that’s too much work

Having to pull the recent changes, rebase these, push back into a branch, prepare a nice pull-request, hope for the CI/CD to pass, and on top of it actually write all the code :exploding_head:… There should be a better way!

Thanks to other people going though this ~pain~ complicated process of producing high-quality software, our favourite code hosting platforms most likely built a solution for us.

In our case, I’ll be describing our Github setup, but there’s a good chance Gitlab or our Frog Nation Web3 Radicle has something similar.

Above is an example of these two magical options. The last two options are replacing the generic merge option which was causing the New Order branches log. The options can be found in the main page of the repository settings and can be toggled with two clicks.

We already touched on the idea of git rebase, which literally means that git will re-organize the commits inside a branch to follow a linear order in respect to the original branch (or the branch off which we started working initially). Enabling merges via a rebase, uses the power of the git rebase in order to communicate if a branch can be easily merged without creating a merge commit before you hit the merge button.

This is all great, but it would still require the author of the pull-request to potentially go back, and re-work the commits. Especially in situations where a pull-request went through a lot of refactoring and brings dozens of commit along with the merge.

This is where git merge --squash shines, the second option in the above screenshot. With a squashed merge, any craziness happening inside the pull-request branch can be compressed into one single commit. This is particularly useful when ~testing in prod~ a feature required lots of back-and-forth!

To wrap it up, I personally find the git log aesthetics quite important, from the commit message to the cleanliness of the log procuced by the team. So to me, these two features are indispensable when setting up, especially open-source repositories or, new projects. Now I know this is all minor details, but next time you see a clean codebase log, you know you might want to work with that team :wink:

N.B.: Just wanted to mention, that if this gist of information created more confussion than helped, the same folks from Github, prepared a long and visual guide on how these settings work.