Squash and Rebase — My Method for Merging Git Branches

I find Git to be somewhat like coffee.
Once I’ve found a method that works for me - I stick to it.

Today I want to share with you my method for merging Git branches (no, this is not another post about merge vs. rebase).
Like the first espresso of the day, let’s start by cutting straight to the chase:

And now, let’s break it down and understand what is happening here.

1. Squash All the Commits in Your Branch

The way I work with Git is that I open a new branch every time I have a new idea. I can have a main feature branch and some smaller branches for testing new ideas. I make several commits a day; sometimes several commits an hour — every time I manage to make the next step work.

This habit of frequent commits poses a challenge when I want to merge my branch to master (or my mini branch to the main feature branch) — I then have numerous commits that have no value for the master branch. Furthermore, if I would like to use rebase later, these commits are likely to cause unnecessary conflicts.

Fortunately, I can discard those expendable commits using a squash. Squashing commits means rewriting Git history to include only the meaningful commits, and I recommend using interactive rebase (Hebrew) to achieve this.

To be precise, we are going to:

1. Go to the branch we want to merge.
2. Open a new branch my_branch_squashed.
3. Rebase my_branch_squashed on top of the last commit from master before my_branch.

Open my_branch_squashed from the latest commit on my_branch. Rebase on the latest master commit before my_branch (m2). After the rebase, the only commits on my_branch_squashed will come straight after m2.

2. Rebase on Master

Now that we have a branch with only meaningful commits after master, we are ready to rebase this branch on the latest master commit.

Open my_branch_squashed_rebased from the latest commit on my_branch_squashed. Rebase on master. After the rebase, the new commits on my_branch_squashed_rebased will come straight after the latest master commit.

Note: some would claim that my_branch_squashed_rebased is redundant and that the rebase on master can happen straight from my_branch_squashed. My philosophy is that there are always shortcuts to be made; in Git and generally in software development. I am not looking for shortcuts that will save me little time now; I am looking for methodologies that will (mostly) save me a lot of time, all the time. Applying this philosophy to the merging method in this post: I prefer to have multiple branches with indicative names, than fewer yet meaningless branches.

3. Merge With No Conflicts

If we did everything right up until now, we have a branch called my_branch_squashed_rebased, that has only meaningful commits on it, that comes after the latest commit on master.

Now we can effortlessly merge this branch, knowing there will be no conflicts.

After merging, you will have added only your meaningful commits to master.

4. Bonus Episode — Delete Old Branches

Now that we have all these branches… what are we going to do with all that green waste?

Once I am sure I did everything right, I wait a couple of days to be sure some more, and then I delete my old branches using three simple steps:

1. Delete branches from the local repository.
2. Delete branches from the remote repository.
3. Prune branches: delete the memory of the remote branches in my local repository.

Epilogue

I enjoy working with Git and find it to be a paramount modern developer tool. But the thing with Git is that I don’t know what I don’t know. And even if I know I don’t know something — it’s difficult to understand what to look for…

Which is why when I find something that works for me, gets the job done, solves my problems… I stick to it. And I also make an effort to share the knowledge so that other people may benefit from my experience as well.

So I hope this post helped you!

When you need something from Git, but you don’t know what you need from Git.