Version Control on kenji.blog

[Git Commands] The Difference Between rebase and merge, and How to Use Them Properly in Practice

Sun, 13 Sep 2026 09:00:00 +0900

1. Introduction: Why “merge vs. rebase” is an Eternal Question

Git is an essential version control system in modern software development. When multiple developers make changes to a codebase simultaneously, Git’s powerful branching model proves its worth. However, in team development, the debate over “whether to use merge or rebase” is a topic that constantly troubles developers, from beginners to experts.

In this article, we will delve deeply into the mechanical differences between git merge and git rebase by unraveling Git’s internal structure, such as the DAG (Directed Acyclic Graph) and the mathematical properties of commit hashes. Then, we will thoroughly explain how to use them properly in practice, incorporating specific workflows. By understanding not just the commands but also the calculations Git performs behind the scenes, you will eliminate the fear of conflicts and become able to build a clean, traceable history.

2. Git’s Internal Structure: Commit Hashes and the Object Model

To understand how Git integrates history, you first need to know how Git stores data. Git does not merely save the diffs (patches) of file changes; it saves a snapshot of the entire file system at a given point in time.

2.1 Cryptographic Properties of Commit Hashes

Each commit in Git is uniquely identified by a 40-character hexadecimal number generated by the SHA-1 (Secure Hash Algorithm 1) hash function, which is calculated based on its contents. A commit object consists of the following elements:

Pointer to a Tree object: A snapshot of the directory structure and files (Blobs) at that time
Pointers to parent commits: The hash values of one or more parent commits (the initial commit has no parents, while a merge commit has two or more parents)
Author information: The person who wrote the code and the date/time
Committer information: The person who created/applied the commit and the date/time
Commit message: Text explaining the intent of the changes

Expressed mathematically, the hash value $H(C)$ for a commit object $C$ is defined as follows:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

Here, $\parallel$ represents the concatenation of data. Due to the characteristics of hash functions, even changing a single character in the commit message or having a different parent commit generates an entirely different hash value. In other words, commits are immutable. The reason why rebase (discussed later) is described as “rewriting history” is that it actually “creates new commits with similar content but different hash values.”

The size of the hash space is $2^{160}$, and the probability $P$ of a collision (different commits having the same hash value) can be approximated using the theory of the Birthday Paradox as follows ($n$ is the number of commits):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

This probability is extremely low, and practically speaking, it is almost impossible for Git commit hashes to collide.

3. Graph Theory and DAG: The Mathematical Model of Git History

Git’s commit history is modeled as a “Directed Acyclic Graph (DAG)” in graph theory.

3.1 What is a DAG (Directed Acyclic Graph)?

In a graph $G = (V, E)$, $V$ is a set of commits (vertices), and $E$ is a set of directed edges indicating the parent-child relationship between commits. In Git, the direction of the edges points from the “child commit to the parent commit.” This is because new commits hold a pointer to past commits.

graph BT
A["Commit A (Initial)"]
B["Commit B"]
C["Commit C (Main)"]
D["Commit D (Feature)"]
E["Commit E (Merge)"]
B --> A
C --> B
D --> B
E --> C
E --> D

The most significant feature of a DAG is that “there are no cycles.” This ensures that the algorithm tracing the commit history never falls into an infinite loop and can reliably reach the end (the initial commit).

3.2 Topological Sort and the Order of History

When displaying history with commands like git log, the DAG is ordered as a one-dimensional list using a Topological Sort algorithm. For any directed edge $u \to v$ in the DAG ($u$ is a child of $v$), it rearranges them so that $u$ comes before $v$ in the list.

4. The Mechanisms and Types of git merge

The most basic command to integrate changes from a branch is git merge. However, Git automatically selects different merge strategies depending on the current state.

4.1 Fast-Forward Merge (–ff)

If the branch you are merging into (e.g., main) is a direct ancestor of the branch you are merging from (e.g., feature), Git performs a “Fast-Forward” merge. This is an operation that simply moves the branch pointer forward without creating a new commit.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

A Fast-Forward merge keeps the history straight, but it has the disadvantage of losing the context of “which group of commits were grouped together as a single feature development (feature).”

4.2 Non-Fast-Forward Merge (–no-ff)

If you explicitly specify git merge --no-ff, it will always create a new “merge commit,” even in a situation where a Fast-Forward is possible. A merge commit is a special commit that has two parents.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Main Work 1"
merge feature type: NORMAL

The advantage of this method is that the existence and history of the feature branch clearly remain on the DAG. If an issue occurs, you can safely undo (revert) the entire feature at once by running git revert -m 1 <merge commit hash>.

4.3 3-Way Merge Algorithm

When both the target and source branches have their own unique commits, Git performs a 3-way merge. At this time, Git traverses the DAG and finds the “Lowest Common Ancestor (LCA)” of the two branches.

The time complexity $T_{\text{LCA}}$ of the algorithm to find the LCA can be executed in linear time relative to the number of vertices $|V|$ and edges $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Git compares three states: the “state of the LCA,” the “state of the current branch,” and the “state of the other branch.” If the changes do not conflict, it automatically generates a merge commit.

5. The Mechanism of git rebase and Reconstructing History

While git merge “integrates” history, git rebase “reconstructs (re-attaches)” history.

5.1 The Movements Behind Rebase

The internal operation when rebasing the feature branch onto the main branch (git rebase main) is as follows:

Find the lowest common ancestor (LCA) of the feature branch and the main branch.
Save the diffs of the commits from the LCA to the tip of the feature branch in a temporary area.
Move the pointer of the feature branch to the tip of the main branch.
Apply the saved diffs one by one sequentially onto the new base (the tip of main) (Cherry-Pick) to generate new commits.

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C (Main)"]
B --> D["Commit D (Old Feature)"]
D -.-> E["Commit D' (New Feature)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

What’s important here is that the commit $D'$ generated by the rebase has a completely different hash value because its parent commit is different from the original commit $D$ (refer to the definition of the hash function $H(C)$ mentioned above).

5.2 Interactive Rebase

Using git rebase -i (or --interactive), you can manipulate the commit history as you wish. This is the most powerful tool for organizing local history.

pick: Use the commit as is
reword: Modify only the commit message
edit: Pause to amend the contents of the commit
squash: Meld this commit into the previous commit, combining their messages
fixup: Same as squash, but discards the message of this commit
drop: Completely remove the commit

Mathematically speaking, if a branch has $N$ commits, the permutations (variations of linear history) $P$ that can be generated by reordering during a rebase are as follows:

$$ P = N! $$

Git gives developers the freedom of $N!$ ways, allowing them to keep the history in a logical and beautiful state.

6. The Golden Rule of Rebase

rebase is incredibly powerful, but there is one absolute rule.

“Never rebase public history” (Never rebase public history)

6.1 Why should you not rebase public history?

Git is distributed. The commits you pushed to origin/main are also cloned to the local repositories of other developers. If you rewrite the history by rebasing commits that have already been pushed, and force-overwrite them with git push --force, what will happen?

The DAGs on other developers’ local machines and the remote DAG will fundamentally diverge. When other developers run git pull, Git will forcefully try to merge the groups of commits with different histories, causing a massive amount of conflicts and duplicate commits (commits with the same changes but different hashes), and the repository will fall into a state of panic.

The ironclad rule is to perform rebases “only on local branches that you haven’t shared with anyone yet.”

7. Resolving Conflicts and git rebase –continue

When multiple people change the same part of the same file, a conflict occurs. The process of resolving conflicts differs between merge and rebase.

7.1 Conflict Resolution in Merge

In the case of git merge, conflict resolution happens only once. You fix all the conflicting parts at once right before creating the final merge commit.

7.2 Conflict Resolution in Rebase

In the case of git rebase, because commits are re-applied one by one, conflicts can occur at each commit.

When a conflict occurs during a rebase, Git pauses the process. The flow of resolution is as follows:

Open your editor or IDE (like VS Code) and manually fix the conflict markers (<<<<<<<, ======, >>>>>>>).
Add the modified files to the index:
1

git add <modified_file>
Do not create a commit, just resume the rebase process:
1

git rebase --continue

If you want to cancel the rebase itself and return to the original state, run the following command:

1

git rebase --abort

(* If you don’t need to resolve the conflict and want to skip that entire commit, use git rebase --skip)

8. Proper Usage in Practice (Workflow Practice)

So, how should you properly use merge and rebase in an actual development environment? Here we introduce the most standard and safe approach.

8.1 [Scenario 1] Organizing Local Working History (Using Rebase)

Suppose you are developing on a feature branch, and many minor commits (“typo fix”, “temporary save”, etc.) have piled up. Before submitting a Pull Request (PR), you use interactive rebase to organize these into meaningful units.

1
2
3


# Execute while on the feature branch
git rebase -i HEAD~5
# (The editor opens, and you clean up the history using squash and fixup)

By doing this, you can create a beautiful commit history whose intent is easy for reviewers to understand.

8.2 [Scenario 2] Catching Up with the Latest main Branch (Using Rebase)

If development drags on and other people’s changes keep getting merged into the main branch, your feature branch will become outdated. In this case, you rebase your feature branch onto the latest main to catch up.

1
2
3
4
5


# Fetch the latest information from main
git fetch origin

# Rebase the feature branch onto the latest main
git rebase origin/main

This keeps the history linear and prevents conflicts during subsequent merges. It also prevents the generation of unnecessary merge commits (“Merge branch ‘main’ into feature”).

8.3 [Scenario 3] Integrating Completed Features (Using Merge)

Development on the feature branch is complete, and it is finally the phase to integrate it into the main branch. Here, we use git merge --no-ff (This is the same as choosing “Create a merge commit” in a Pull Request on GitHub, etc.).

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: Implement user login functionality"
git push origin main

By doing this, a node in history (a merge commit) saying “a single feature was merged here” is left on the DAG of the main branch. When looking back at the history later, it becomes easier to trace the code by feature units.

9. Conclusion (Summary)

In Git operations, extreme approaches like “doing everything with Merge” or “making everything linear with Rebase” each have their pros and cons.

The best practice in real-world environments is a hybrid approach: “Cleanly organize local private history with rebase, and preserve context in public integration history with merge –no-ff.”

Local (Personal workspace): Use rebase to eliminate useless commits, catch up with the latest mainline, and maintain a linear history.
Global (Shared workspace): Use merge --no-ff to record the existence of a feature branch as a merge commit on the DAG, making reverts and tracking easier.

By understanding the mathematical and architectural backgrounds, such as the structure of the DAG and how hash functions work, Git commands are elevated from mere memorization to “designing history with intent.” While adhering to the golden rule of rebase, let’s select the optimal commands depending on the situation and build a clean commit history that is easy to read and maintain for the entire team.

A Collection of Common Mistakes and Solutions for Git Beginners (Including Conflict Resolution)

Sat, 12 Sep 2026 17:00:00 +0900

A Collection of Common Mistakes and Solutions for Git Beginners (Including Conflict Resolution)

1. Introduction: Why Do We Make Mistakes in Git?

In software development, Git has become as essential as air and water. However, for many beginners (and sometimes even experts), Git can feel like a “terrifying magical black box”. Commits disappear, massive amounts of changes are pushed into the wrong branch, or unfamiliar conflict error messages fill the screen… Falling into these “Git traps” can completely halt your work progress and make you fear that you might destroy the source code in the worst-case scenario.

Why is Git so difficult and prone to inducing mistakes? The biggest reason is that people use it by simply memorizing superficial commands without understanding what is happening inside Git. Git is based on a robust design philosophy as a Distributed Version Control System (DVCS), but its interface (CLI) is not always intuitive.

This article categorizes many “screw-ups” (common mistakes) that Git beginners frequently encounter in the field into numerous cases and presents specific commands as solutions for each. However, it will not just be a simple list of commands (a cheat sheet). We will thoroughly dive deep into “why that mistake happens” and “how the data moves inside Git when you execute that command”, exploring the structure of the .git directory, the mathematical background of the Diff algorithm working behind the scenes, and Mermaid diagrams in a volume exceeding 10,000 characters.

By the time you finish reading this article, you should be free from the feeling that “Git is scary” and instead be convinced that “there is no more reliable partner than Git.” Now, let’s dive into the profound world of Git.

2. The Abyss of Git: Understanding the Internal Structure of the `.git` Directory

The first step to making many troubleshooting tasks easier is knowing how Git stores data. The hidden folder .git that exists in the root directory of your project is exactly the heart of Git. Git is not a system that merely records file differences (patches) sequentially, but it manages data as a stream of snapshots.

2.1 Object Model: Blob, Tree, Commit

Git mainly uses three objects to represent the state of a repository. These objects are saved in .git/objects.

Blob (Binary Large Object) An object that stores the file content itself. File names and permission information are not included here. Pure byte sequences are compressed with zlib and identified by a SHA-1 hash value (a 40-character hexadecimal number).
Tree An object that represents the structure of a directory. A Tree object contains pointers (SHA-1 hash values) to other Tree objects (subdirectories) and Blob objects (files), as well as their file names and access permissions. It plays a role similar to a UNIX directory.
Commit Holds a pointer to the top-level Tree object of the entire repository at a given point in time, metadata (author, commit date and time, commit message), and a pointer to the immediately preceding commit (parent commit).

graph TD
Commit1["Commit (Hash: 9f8a)"] --> Tree1["Tree (Hash: 4b82)"]
Tree1 --> Blob1["Blob (Hash: 8d7e) : index.js"]
Tree1 --> Tree2["Tree (Hash: 3a2c) : src/"]
Tree2 --> Blob2["Blob (Hash: 5f1b) : app.js"]

2.2 The True Identity of HEAD and References (Refs)

When working with Git, you frequently see the word HEAD. This is a Symbolic Reference that points to the currently checked-out branch (or commit). If you open the .git/HEAD file in a text editor, you will see a string like the following:

1

ref: refs/heads/main

This means that “the current state is at the tip of the main branch.” And when you open .git/refs/heads/main, there is a 40-character SHA-1 hash written there, which points to the latest Commit object. A branch in Git is simply a lightweight pointer (file) that points to a specific commit. Just knowing this fact removes the fear that “if I delete a branch, will all the files be deleted?”.

3. Deciphering Git with Mathematics: Diff Algorithms and Hash Functions

When Git detects conflicts or displays file differences, sophisticated algorithms are running internally.

3.1 Myers’ Diff Algorithm

Git’s default difference detection algorithm is the one devised by Eugene W. Myers. When there are two text files $A$ and $B$, the problem of finding the “minimum edit script (insertions and deletions)” to transform $A$ into $B$ can be modeled as a shortest path problem in graph theory.

Let the lengths of the strings be $N$ and $M$ respectively, and the sum be $V = N + M$. Myers’ algorithm searches for the Edit Distance $D$. The time complexity of this algorithm is expressed by the following formula:

$$ \mathcal{O}(V \cdot D) $$

Here, if the difference between the files is small (that is, $D$ is small), the algorithm operates very fast at $\mathcal{O}(V)$. However, if the files are completely different, $D \approx V$, and the worst-case time complexity becomes $\mathcal{O}(V^2)$.

3.2 Patience Diff and Histogram Diff

While Myers’ algorithm is excellent, it can sometimes generate differences that are not intuitive (do not make sense) to humans, such as when the order of functions or classes is significantly rearranged. To solve this, Git implements Patience Diff and Histogram Diff.

Patience Diff focuses on “unique lines that appear exactly once in both files” and finds their Longest Common Subsequence (LCS). Letting the number of unique elements be $U$, the computation of the LCS can be solved with the following time complexity:

$$ \mathcal{O}(U \log U) $$

When you feel that conflict resolution is difficult, using git diff --histogram or specifying this algorithm in the merge strategy (git merge -s recursive -X histogram) is one solution.

3.3 SHA-1 and Collision Probability

Git manages all objects with SHA-1 hash values. The size of the hash space is $2^{160}$. Approximating the probability of hash collision (different contents having the same hash value) using the Birthday Paradox, the number of objects $k$ required for the collision probability $p$ to reach 50% is as follows:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

This is an astronomical number, and the probability of an unintended collision occurring in normal software development is practically zero. Therefore, Git operates by trusting the hash value as an “absolute unique ID”.

4. Case Study 1: I Committed to the Wrong Branch!

[Situation] Without realizing that I was working on the main branch, I actively wrote code for a new feature and even went as far as doing a git commit. I was supposed to create a feature/login branch and work there!

Solution: `git reset` and Creating a Branch

In Git, a commit is an independent object, and a branch is just a pointer. Therefore, you can instantly solve this with the operation: “create a new branch and then rewind the pointer of the current branch.”

1
2
3
4
5
6
7
8
9


# 1. Create a new branch pointing to the current commit (the mistakenly created commit)
$ git branch feature/login

# 2. Rewind the pointer of the main branch to the previous commit (HEAD~1)
# Using --keep allows you to safely reset while maintaining uncommitted changes in the working directory.
$ git reset --keep HEAD~1

# 3. Switch to the correct branch
$ git checkout feature/login

Diagram: What Happened Internally?

Let’s visualize the movement of branch pointers at this time using a Mermaid gitGraph.

gitGraph
commit id: "Initial commit"
commit id: "Bugfix"
commit id: "Mistaken Commit" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

Initially, main and HEAD were pointing to “Mistaken Commit”, but with git branch feature/login, a new pointer is created there. After that, by using git reset, only the main pointer returns to the “Bugfix” position. The objects themselves are not deleted at all.

5. Case Study 2: I Want to Cancel an Already Pushed Commit!

[Situation] I committed bug-ridden code written in a late-night frenzy, and what’s more, I published it to the remote repository with git push origin main. I noticed a critical bug and turned pale.

Solution 1: Deny History with `git revert` (Recommended / Safe)

In team development, tampering with the history of already pushed commits using git reset or similar is strictly prohibited. It causes inconsistencies with the local repositories of other developers. The correct approach is to “create a new commit that does the exact opposite, completely neutralizing the changes of the mistaken commit.” This is git revert.

1
2
3
4
5
6
7


# Create a commit that neutralizes the latest commit
$ git revert HEAD
[main 7f3a8b2] Revert "Commit message of the mistaken commit"
 1 file changed, 1 insertion(+), 10 deletions(-)

# Push to remote
$ git push origin main

gitGraph
commit id: "Commit A"
commit id: "Commit B (Mistake)"
commit id: "Revert Commit B" type: REVERSE

History continues to move forward, and only the state of the code reverts to its original form.

Solution 2: Falsify History with `git push --force-with-lease`

If you have just pushed to a branch that only you are using, rewriting history is acceptable.

1
2
3
4
5
6
7


# Reset the commit locally and fix it
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Correct implementation"

# Forcefully overwrite the remote history
$ git push origin feature/login --force-with-lease

--force-with-lease is a safe forced push to prevent accidents where you mistakenly overwrite someone else’s work.

6. Case Study 3: I Want to Switch to Another Branch Mid-Work (The Magic of Stash)

[Situation] While implementing a new feature on the feature/A branch, the source code is in a half-finished state where it doesn’t even compile yet. Suddenly, an order flies in from my boss: “There is an urgent bug in the production environment of the main branch, so fix it right now!”

Solution: Shelve with `git stash`

git stash is a command to temporarily shelve uncommitted changes to a temporary area.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. Shelve the changes being worked on
$ git stash push -m "WIP: feature A partially implemented"

# 2. Make it possible to switch to the main branch
$ git checkout main
# ... (perform emergency bug fix work, commit, and push) ...

# 3. Return to the original branch when work is finished
$ git checkout feature/A

# 4. Restore the shelved changes
$ git stash pop

When you execute git stash, Git internally generates two special commit objects and saves them to a reference called refs/stash. In other words, Stash is also ultimately an “unnamed temporary commit”.

7. Case Study 4: The Terrifying “Detached HEAD” State

[Situation] I wanted to check the code at a specific point in the past, so I executed git checkout 9f8a7b6. Then, You are in 'detached HEAD' state. was displayed. I committed as it was, but when I switched branches, the commit disappeared!

Mechanism of Detached HEAD

Normally, HEAD points to a branch like refs/heads/main. However, if you directly check out a specific commit, HEAD points directly to the commit object. This is called a Detached HEAD.

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C"]
C --> D["Commit D"]
BranchMain["Branch: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

Even if you stack commits in this state, no branch will track those new commits. The moment you switch to another branch, the new commits become lost.

Solution: Save as a New Branch

It will be resolved if you create a new branch at your current location.

1
2


# Create a new branch at the current HEAD position and switch to it
$ git checkout -b feature/recovered-work

8. Case Study 5: Conflict Resolution in Merge and Rebase

[Situation] When I executed git merge or git rebase, CONFLICT (content) was displayed, and the process was interrupted.

Difference Between Merge and Rebase

Merge Performs a 3-way merge using the latest commits of the two branches and their common ancestor, creating a merge commit.
Rebase Temporarily saves the commits of the current branch and reapplies them to the tip of the target. History becomes a straight line.

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

Conflict Resolution Method

Markers like the following are inserted into files where conflicts have occurred.

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

The resolution procedure is extremely simple.

Delete the markers and correct the code to the right one.

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

Add the resolved file to staging. git add has the role of “telling Git that the conflict has been resolved”.
1

$ git add index.js

Complete the process.

1
2
3
4
5


# In the case of merge
$ git commit -m "Resolve merge conflict in index.js"

# In the case of rebase
$ git rebase --continue

If you panic, you can abort at any time with $ git merge --abort or $ git rebase --abort.

9. Case Study 6: The Commit History is a Mess! `git rebase -i`

[Situation] A large number of minor commits like “Fix typo”, “Fix again”, and “Add test” have occurred. If merged into main like this, the history will be messy.

Solution: Interactive Rebase

Using git rebase -i (interactive), you can rearrange the order of past commits, combine multiple commits into one (squash), or modify commit messages.

1
2


# Organize the last 3 commits
$ git rebase -i HEAD~3

An editor opens, and it displays as follows:

1
2
3


pick 1a2b3c4 Fix typo
pick 2b3c4d5 Fix again
pick 3c4d5e6 Add test

Rewrite this as follows:

1
2
3


pick 1a2b3c4 Implement feature X
squash 2b3c4d5 Fix again
squash 3c4d5e6 Add test

When you save and close, these three commits are beautifully integrated into one.

10. Case Study 7: I Don’t Know When the Bug Was Introduced! `git bisect`

[Situation] There is a bug in the current main branch, but it was normal when released a month ago. I want to identify which commit introduced the bug, but there are over 100 commits, making it impossible to do manually!

Solution: Identifying Bugs via Binary Search

Git has a built-in tool that finds the commit where a bug was introduced through a mathematical Binary Search. Since the time complexity is $\mathcal{O}(\log N)$, even with 1000 commits, it can be identified in about 10 tests.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Start the search
$ git bisect start

# The current commit has a bug (bad)
$ git bisect bad

# It was normal 1 month ago (for example, hash a1b2c3d) (good)
$ git bisect good a1b2c3d

# Git will automatically checkout a middle commit, so run your test
# If the test succeeds:
$ git bisect good
# If the test fails:
$ git bisect bad

By simply repeating this, Git will accurately tell you, “This commit is the first bad commit.” When finished, use $ git bisect reset to return to the original state.

11. The Ultimate Safety Net: `git reflog`

The ultimate secret technique against any “screw-up” in Git is git reflog. Git records all local operation history (movements of HEAD) for a certain period of time. Even if you mistakenly delete a branch or perform an incorrect reset, you can recover just by finding the past hash with git reflog and doing a git reset --hard to it.

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. Conclusion

We have explained in great detail the mistakes that Git beginners easily fall into, the mechanisms of Git behind them, and how to solve them. Committing to the wrong branch, reverting pushed commits, utilizing Stash, surviving from a Detached HEAD, and resolving conflicts. What is important in all of these is to imagine “what objects and pointers Git is manipulating behind the scenes.”

File differences are calculated by strict Diff algorithms expressed in mathematical formulas, and the consistency of history is guaranteed by cryptographic hash functions. If you understand this beautiful design philosophy, you should realize that Git is by no means a “mysterious black box,” but the strongest shield that firmly protects your source code.

Next time you think “I screwed up!”, don’t panic and close the terminal, but take a deep breath and type git status. Git will surely present you with hints for recovery.

Version Control on kenji.blog

[Git Commands] The Difference Between rebase and merge, and How to Use Them Properly in Practice

1. Introduction: Why “merge vs. rebase” is an Eternal Question

2. Git’s Internal Structure: Commit Hashes and the Object Model

2.1 Cryptographic Properties of Commit Hashes

3. Graph Theory and DAG: The Mathematical Model of Git History

3.1 What is a DAG (Directed Acyclic Graph)?

3.2 Topological Sort and the Order of History

4. The Mechanisms and Types of git merge

4.1 Fast-Forward Merge (–ff)

4.2 Non-Fast-Forward Merge (–no-ff)

4.3 3-Way Merge Algorithm

5. The Mechanism of git rebase and Reconstructing History

5.1 The Movements Behind Rebase

5.2 Interactive Rebase

6. The Golden Rule of Rebase

6.1 Why should you not rebase public history?

7. Resolving Conflicts and git rebase –continue

7.1 Conflict Resolution in Merge

7.2 Conflict Resolution in Rebase

8. Proper Usage in Practice (Workflow Practice)

8.1 [Scenario 1] Organizing Local Working History (Using Rebase)

8.2 [Scenario 2] Catching Up with the Latest main Branch (Using Rebase)

8.3 [Scenario 3] Integrating Completed Features (Using Merge)

9. Conclusion (Summary)

A Collection of Common Mistakes and Solutions for Git Beginners (Including Conflict Resolution)

A Collection of Common Mistakes and Solutions for Git Beginners (Including Conflict Resolution)

1. Introduction: Why Do We Make Mistakes in Git?

2. The Abyss of Git: Understanding the Internal Structure of the .git Directory

2.1 Object Model: Blob, Tree, Commit

2.2 The True Identity of HEAD and References (Refs)

3. Deciphering Git with Mathematics: Diff Algorithms and Hash Functions

3.1 Myers’ Diff Algorithm

3.2 Patience Diff and Histogram Diff

3.3 SHA-1 and Collision Probability

4. Case Study 1: I Committed to the Wrong Branch!

Solution: git reset and Creating a Branch

Diagram: What Happened Internally?

5. Case Study 2: I Want to Cancel an Already Pushed Commit!

Solution 1: Deny History with git revert (Recommended / Safe)

Solution 2: Falsify History with git push --force-with-lease

6. Case Study 3: I Want to Switch to Another Branch Mid-Work (The Magic of Stash)

Solution: Shelve with git stash

7. Case Study 4: The Terrifying “Detached HEAD” State

Mechanism of Detached HEAD

Solution: Save as a New Branch

8. Case Study 5: Conflict Resolution in Merge and Rebase

Difference Between Merge and Rebase

Conflict Resolution Method

9. Case Study 6: The Commit History is a Mess! git rebase -i

Solution: Interactive Rebase

10. Case Study 7: I Don’t Know When the Bug Was Introduced! git bisect

Solution: Identifying Bugs via Binary Search

11. The Ultimate Safety Net: git reflog

12. Conclusion

2. The Abyss of Git: Understanding the Internal Structure of the `.git` Directory

Solution: `git reset` and Creating a Branch

Solution 1: Deny History with `git revert` (Recommended / Safe)

Solution 2: Falsify History with `git push --force-with-lease`

Solution: Shelve with `git stash`

9. Case Study 6: The Commit History is a Mess! `git rebase -i`

10. Case Study 7: I Don’t Know When the Bug Was Introduced! `git bisect`

11. The Ultimate Safety Net: `git reflog`