Why Is Your Git History Important?
Imagine you are part of a large project with 15 developers. Dozens of Pull Requests are merged every day. If everyone uses the default Merge command, the Git Network Graph will soon become a “tangled mess of wires,” overlapping and intertwining. At that point, tracing a bug or finding a specific change is like looking for a needle in a haystack.
When you need to update your feature branch with the latest code from main, you usually face a fork in the road: Merge or Rebase. Both solve the same problem, but the way they leave their mark on history is completely different.
- Merge: Combines two branches and creates a new “merge commit.” This method keeps the history intact, including failed merges or messy intermediate code.
- Rebase: “Rewrites” history by moving all your commits to the top of the target branch. The result is a perfectly linear path that is extremely easy to read.
I once worked with a very demanding Tech Lead. He required every commit to be cleaned up before hitting production. At first, I found it annoying, but when the project hit the 1,000-commit mark, I finally understood the value of a “clean” history. It allowed git bisect to find the commit causing a bug in minutes rather than hours.
Preparing Your Environment Before Starting
Never start a rebase when your local base code is outdated. The first step is to sync with the server to avoid unnecessary conflicts.
# Update the latest information from the server
git fetch origin
# Switch to the feature branch you are working on
git checkout feature-xyzA small tip for observing the difference: set up the git adog alias. This command helps you view the commit graph as a tree directly in the terminal, which is much more intuitive than the default log command.
git config --global alias.adog "log --all --decorate --oneline --graph"Detailed Comparison: Safe Merge and Elegant Rebase
1. Git Merge: The “Preserve the Scene” Option
When you merge main into feature, Git performs a 3-way merge to create a merge commit.
git checkout feature-xyz
git merge mainThis method is extremely safe because it doesn’t change existing commits. However, if you merge constantly to update your code daily, your branch will be littered with commits like “Merge branch ‘main’ into…”, cluttering the project history.
2. Git Rebase: The Art of Storytelling History
Rebase works differently. It temporarily lifts your commits, updates the feature branch to the latest version of main, and then places your commits back on top.
git checkout feature-xyz
git rebase mainAt this point, the history looks as if you just started coding on the latest foundation. Everything happens in a perfect chronological sequence.
The Power of Interactive Rebase:
During the coding process, we often have trivial commits like “fix typo” or “misc updates.” Before pushing, use interactive mode to squash 10 messy commits into a single meaningful one:
git rebase -i HEAD~5 # Edit the 5 most recent commitsIn the editor that appears, change pick to squash (or s) for the secondary commits. Git will combine them all into the main commit directly above.
The Golden Rule: When to Use Which?
To maintain a professional workflow, you can apply the following formula:
- Use Rebase: For personal branches (local branches). Clean up your commits and make them look beautiful before sharing them with the world.
- Use Merge: When merging a completed feature into a shared branch (like
main). This preserves a clear milestone: “Feature X was integrated at this point.”
Critical Warning: Never rebase on public branches where others are working. This changes the commit hashes, causing serious history conflict errors for your colleagues when they pull the code.
Handling Conflicts and Pushing Safely
Conflicts are inevitable. When rebasing, conflicts can occur at each commit rather than just once like a merge. Don’t panic; fix the code and run:
git add .
git rebase --continueIf things get too messy, you always have a way out with: git rebase --abort. This command will return your branch to its original state as if nothing happened.
After a successful local rebase, you won’t be able to push normally. Use the following safe command:
git push --force-with-leaseWhy --force-with-lease? Unlike a blind --force, this command will refuse to push if someone else has pushed new code to that branch that you haven’t updated yet. This is the final safeguard to prevent you from accidentally overwriting and losing a colleague’s work.
In short, use Merge to respect historical facts and use Rebase to retell that story as coherently as possible.
