Hide your shameful commits with Git Squash
Tags: devops, git
Published: 2019-08-07 11:39:22

---
title: Hide your shameful commits with Git Squash
published: true
canonical_url: https://pushbuildtestdeploy.com/hide-your-shameful-commits-with-git-squash/
description: We all have those embarrassing rapid commits. This is how you can modify them before merging to other branches.
tags: DevOps, git
cover_image: "https://thepracticaldev.s3.amazonaws.com/i/saywnoe1n3p3iukpvh43.png"
---

We all do it, and I'm sure that you do too. You know, the rapid commits when you are testing something, then fixing a typo, then commit again, push, test and on and on.

![Real Git log from one of my projects](https://thepracticaldev.s3.amazonaws.com/i/cbzshtbo4g1oxgac5lw6.png)

I usually do it when I'm working on deployment or build code, positive that it's just a tiny fix, one little modification and that's it. So I commit with a meaningless message, push test and, see an error.
Let's call it *BDD*: Brute-Force Driven Development.

Now I'm left with a branch full of, well, embarrassing commits that are heading straight to a pull request and code review.

However, I do have a little trick up my sleeve that helps me push those changes like that 10x engineer on my team.

Use git squash. Other than looking smarter, you can keep the history of the branch cleaner and much more readable for others.

## Git Squash
Squashing commits can be done in a few ways, where your end goal is to rewrite the commit history and leave just one commit instead of multiple meaningless ones. You can choose to leave the commit message history or rewrite that as well, so it's another opportunity to communicate the changes you introduce.

### git log - before
The best way to understand git squash is to look at the git log. In this example, I have a feature branch that has three commits.

```git
* 510b129 (HEAD -> docker-rmi) missing flag
* cd62deb typo #2
* dba34d5 typo
* 46e95a5 Listing local docker images
* e30e77d (master) Starting the build process
* 9409666 Adding the build script
```

### git log after
After performing a "squash", the git log looks like this:

```git
* 617c65c (HEAD -> docker-rmi) Listing all the local docker images
* 46e95a5 Listing local docker images
* e30e77d (master) Starting the build process
* 9409666 Adding the build script
```

It's like we went back in time!
![Are you tellimg me you built a time machine?](https://thepracticaldev.s3.amazonaws.com/i/qqajkuvljinx0ol6sf87.jpg)


You can see that instead of all the "typo" commit messages and the missing flag, we now have just one commit message that includes all of the changes we made.

There are a few ways to squash commits, and I'll show you two that cover different use cases. [There is a wonderful thread on StackOverflow if you want to see more methods.](https://stackoverflow.com/a/5201642/1092477)

### Squash on the same branch
When you want to alter the branch history, squashing a few commits back, the `git reset --soft` command can come in handy.

*WARNING* - Make sure you don't have uncommitted changes. Either commit or stash them before performing the reset command.

If you want to squash your last three commits run the command:
```bash
git reset --soft HEAD~3 && git commit
```
Also if you want to squash to a specific commit:
```bash
git reset --soft 46e95a5 && git commit
```

To push your changes, you have to use the --force flag, as you altered the branch history.
```bash
git push --force
```

Again, for more, see the link above to the StackOverflow thread.

### Squash on merge
If you are a confident person and just want to keep the master (or any other) branch clean, you can use the `git merge --squash` command. Most of the pull request UIs allow you squash merge as well.
```bash
git checkout master
git merge --squash featurebranch
```

By default, the commit includes all the original messages but, you can rewrite it as well.
Your original branch keeps the original history, so that you can reference it.

### Do this now
Like everything Git, knowing about the method adds another tool to your belt. But then again, there is always this "fear" of running commands for the first time on your existing codebase.
So go ahead and create a clean git repo and try these methods out in a safe environment. Your hand will be less likely to shake once you see how it works on your own.

Want to learn more? 
[Head over to my signup page](https://pushbuildtestdeploy.com/signup) and never miss a post