Dropping commits

Now suppose that we want to drop commit 1736531. To do this, we'll use interactive rebasing. As always, we should start our rebase process with the parent of that commit.


If we take a look at the content of that commit, we see that in that commit we introduced a new file called terms.txt. When we drop this commit we have two possible scenarios that we need to be careful of. If a commit after that one touches that file, and we drop the commit where the file was introduced, then we will get a conflict when the rebasing operation reaches that point in which the file is edited and we will have to resolve it.


The worst-case scenario is when no other commits touch that file, but our program needs it. In this case, we will never get a conflict while rebasing, but we will be introducing a bug in our program (possibly even a breaking bug). So be very careful when dropping commits.


To start the interactive rebase process we run

git rebase -i 1736531^

The caret (^) means that we want to start at the parent of that commit.

Dropping commits 1

Git will now open VS Code so that we can select the operation that we want to perform on each commit. Here we select the drop option for the commit that we want to drop. If you are now using GitLens, you can also just delete the line for that commit. Once we selected all the appropriate options for our commits, we save the file and close it. Here let's start by deleting the first WIP commit.

Dropping commits 2
Dropping commits 3

When we close the file, Git will move forward with the rebase operation. Take a look at the Git Bash image. It's telling us that we are at step 2 of 5 during the rebase process. So the commit that we wanted to drop has been dropped. The next commit edited that file, which now does not exist, so we get a conflict.


If we check the status, we can see that the terms.txt file is been deleted (hence the red D) and modified (hence the red U) at the same time. This is what's creating the conflict.

To solve this conflict we will use the mergetool. So we run

git mergetool

Because I haven't configured a merge tool, Git will use one of the default ones. Git is now asking to choose between one of the two states of the file. In the local commit (the one we are moving out of) the file is deleted. In the remote commit (the one we are trying to move into) the file is modified. Here we choose to keep the file with the modifications, so we select m.


If we now check the status, we see that the terms.txt file is been added (since it was deleted in the previous commit). Notice that there's a new file called terms.txt.orig. This is a file created by the merge tool. Some delete them automatically, but even if the merge tool we are using does not, we can always do so ourselves.


Since all conflicts have been resolved, when we run

git rebase --continue

Git takes care of rebasing all other involved commits.

Dropping commits 4
Dropping commits 5

If we check the log, we can see that the commit is now gone and we have a much cleaner history. Notice that I've also dropped the other WIP commit and the Revert commit too.


Lastly, since Git did not remove the auxiliary file created by the mergetool, we delete it ourselves.