I have a branch named myBranch
, which I'm working on for a complex feature for a long time. After I finished my work and wanted to open a merge request, gitlab showed that 47 commits was done in my branch.
I thought the MR would be easier to understand if there was a single commit combining all the changes, because most of the individual commits were to try different things until it worked.
I heard about the term "squashing" before to combine multiple commits into one, so I decided that I could try and learn that.
I started with:
git rebase -i HEAD~47
It showed me a text file with a list of commits and choices like pick, squash or reword.
There were some old commits unrelated to my work in the text file, so I left them as "pick". I typed "reword" for my first commit in the branch, and changed the commit message to the feature I'm adding with my branch. I typed "squash" for the rest of them, up to the latest commit.
Then the rebase process continued. It stopped a few times for merge conflicts and asked me to fix then add them. I fixed the conflicts, added them using git add -A
then continued with git rebase --continue
.
After a few merge conflict fixes, process completed and I run git push origin myBranch --force
, and tried to open a merge request using my branch.
Now it shows a whopping 101 commits, way more than my initial 47!
Instead of reducing the number of commits into 1, I actually increased them.
What did I do wrong?
Make sure those 47 commits are all from your current work: I always prefer rebasing my branch on top of the target branch first:
That will force you to deal with any merge conflict locally.
And you can do a
git rebase -i origin/target-branch
instead, if you want to squash some commits (as noted by matt in the comments, eachpick
orreword
creates a new commit: an interactive rebase where multiple commits are picked or reworded will not necessarily reduce the number of commits to one).Force push your branch (rebased on top of the target branch) and your merge request should be trivial.