Introduction

In everyday development, when creating PR (Pull Request), I organize the commit history so that it is easy to understand for reviewers and future maintainers (maybe even myself). To achieve this, I consolidate the commit history into as few commits as possible for a single PR by using git rebase -i.

However, since I also rebased the commits that I intended to write about in my technical blog when creating the PR, I ended up geting lost trying to figure out which commit contained the changes I needed when it was time to write the blog.

So, I decided to compile a flow and some points to note on how to retrieve the target commit from the consolidated commits.

Intended Audience

Git Beginners
Beginners in Git Archaeology
Anyone who wants to review commit history before consolidation

Basics of `git rebase -i`

Interactive rebase (git rebase -i) is a powerful Git feature that allows you to organize and reorganize your commit history. With this, you can combine multiple commits, changes the order of commits, or even modify commit messages.

Basic usage of Interactive Rebase

Execute the Command
```
git rebase -i <base_commit>
```
<base_commit> refers to the commit just before the one you want to modify. For example, if you want to operate on the latest 3 commits, you can use:
```
git rebase -i HEAD~3
```

Editor Opens

When you run the command, a text editor opens, listing the commits within the specified range.

pick abc1234 First commit message
pick def5678 Second commit message
pick ghi9012 Third commit message

# Help message for rebase commands...

Specify the Operations

You change the keyword at the beginning of each commit line (default is pick) to specify the operation. The main Operations are as follows:
- pick: Use the commit as is
- reword: Use the commit but change the commit message
- edit: Use the commit and modify its content
- squash: Combine with the previous commit, merging both commit messages
- fixup: Combine with the previous commit, discarding this commit's message
- drop: Delete the commit
Confirm the Changes

After saving and closing the editor, Git executes the specified operations. You can always cancel the rebase with git rebase --abort, so feel free to consolidate commits without worry.

The Process of Combining Commits Using Squash

Now, let's explain how to combine several small commits into one meaningful commit.

rebase_overflow

Start the Rebase

Start the rebase by specifying the range of commits you want to combine.
```
git rebase -i HEAD~4 # Operate on the latest 4 commits
```
Operations in Editor
```
pick abc1234 Main feature implementation
squash def5678 Bug fix
squash ghi9012 Add tests
squash jkl3456 Update documentation
```
In this example, all commits except the first one are changed to squash, combining them into a single commit.
Edit the Commit Message

Once you save the editor, a new editor opens for entering the new commit message. All the commit messages are displayed here, so you can edit them as needed.
Completion

After saving the message, the four commits are consolidated into one.

Dissecting the Internal Structure of Consolidated Commit

Here lies the problem: after consolidating commits, it became difficult to determine what changes were made in the original (pre-consolidation) commits. Referring to the diagram, this specifically relates to the "Bug Fix" commit. I wanted to write a blog post about the work done in that commit, but because of the rebase, the changes were hard to track.

Let's dissect the consolidated commit using interactive rebase to inspect the target commit's contents!

Search for the Pre-Rebase Commit Message

Look through the rebase commit log to find the pre-rebase commit message you're interested in. Especially if, like me, you try to find it long after the commit was made, this step can be the most painstaking.

Using a GUI tool or the git log --pretty=full command, you might get an output like:
```
Feature implementation

Bug fix

Add tests

Refactoring
```
This confirms the existence of a commit message similar to "Bug fix."
Obtain the Commit Hash Using Reflog

Git records its operation history in the reflog. Since the state before the rebase is retained, you can check it with:
```
git reflog
```
You can either manually search through the output or use grep to find the desired commit hash. Once found, copy the hash.
Review the Original Commit

Using the commit hash you found for "Bug fix," run the following command to check the changes made in that commit:
```
git show <commit_hash>
```

Success - you've now confirmed the changes you were looking for!

Summary

In this article, I summarized the steps for reviewing pre-rebase commits from a consolidated commit using interactive rebase. Sometimes, knowing that you will consolidate commits immediately using interactive rebase, you might use meaningless commit messages like hogehoge. Fortunately, because I had given meaningful commit messages to the pre-rebase commits, I was able to locate them quickly. This experience reinforced for me the importance of writing clear commit messages in any case.

Also, if you use fixup instead of squash (thus discarding the previous commit's message), it becomes much harder to track the commit later. Therefore, using squash might be more helpful in the long run. Of course, commit practices often reflect the philosophy of the development organization, so I'd love to hear about various commit philosophies from different teams!

Reference Links

Dissecting Consolidated Commits with Interactive Rebase