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
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
So, let’s say I started my branch
development when there were two commits:
I added one commit to my
In the meantime there was another commit added to
development branch created by
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
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
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
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.
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.