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