I want to tell you about one of mistakes I made quite recently. Actually I made two mistakes - the other one was about deploying at Friday afternoon. Anyway everything is ok now. Let’s dive in into my git story.
My git merge without git rebase story
Our git workflow is quite common one - when we are finished with a task, we
create a PR (pull request) and add reviewers. After it’s approved
by one of them, the author is supposed to merge it to development or master branch.
So I did my PR with a few commits created during few days. I didn’t squash them
to one commit. Also I didn’t rebase my branch to current development branch.
So, let’s say I started my branch feature/file3 from development when there were two commits:
I added one commit to my feature/file3 branch:
In the meantime there was another commit added to development branch created by
another author:
After that I added another commit to feature/file3 branch and I created a PR:
It was approved, so I decided to merge it. And shamefully I did this without rebasing
to current development branch. Running:
$ git checkout development
$ git pull
$ git checkout feature/file3
$ git rebase -i development
could save me plenty of time, because my current changes would be on top of git history after merge.
Instead of that I just clicked merge on bitbucket and it just did something like this:
My commits (these with file3 in title) were between other author commits.
We started to deploy it, but it happen that we wasn’t successful for some reason. That’s way
we wanted to revert my changes and go back to previous version of development branch.
But it wasn’t easy, because it wasn’t enough to go back to commit
d6f1f201fe91cf21c21cba82c2173eab4ccf395a (this with title File 2 fixed typo).
In situation from a picture,
it’s enough to cherry-pick commit c2a4ac986617d1546a18764692d7c9f0cd34aea1
created by another author. In my real situation it was much worse, because
there were more commits in between. There was no point in cherry-picking all commits,
it was better to create a patch.
Summing up
Don’t be lazy - rebase your branch before merging. It will help you avoid many issues when revert is needed. Also the git history will be much more readable - there will be no commits between your changes from that branch. Also I think it’s a good idea to squash all commits into one before merge, because when project becomes big, it’s more easy to study its history - there will be one commit per feature.
Leave a Comment