Select a post from the list.
Privacy Policy
We do not collect, store, or share any personal information.
Git Rebase
At the beginning of my career, I worked at a company that used Perforce, a centralized version control system. It was straightforward to use, but when I moved into Android development, I encountered something very different: most open-source Android libraries and internal workflows were based on Git and Gerrit.
Early Pain: Merge Conflicts Everywhere
Initially, I struggled with Git. Merge conflicts happened frequently. One of the senior engineers suggested using git rebase
to maintain a cleaner history. However, rebase felt more complex than merge, and I got burned by multiple accidents—misplaced commits, lost changes, and confusion over what actually got applied. Eventually, I avoided rebasing and stuck with git merge
.
A Scary Moment: Bad Author Emails
Once, a colleague accidentally made several commits using a non-company email address. As a result, our internal framework refused to publish the binary due to invalid authorship. To fix this, I had to force-squash all offending commits and rewrite history. It was terrifying—any mistake could corrupt our project history.
A Simple, Effective Workflow
Later, I worked with an engineer who had over 15 years of experience. His Git strategy was refreshingly simple:
1. List down all tasks.
2. Start from the simplest one.
3. Commit often. "WIP" messages are okay.
4. At the end of the day, squash everything.
5. Run: git fetch --all && git rebase origin/main
This created a clean commit history with minimal noise and no dangling changes. I adopted this practice.
Confusion: Where Did My Work Go?
One day, a colleague and I were rebasing against origin/main
and encountered a merge conflict in a single file. After resolving it, we noticed some of his work was missing. His local branch had 8 commits. We tried to cherry-pick the missing commits from the remote branch—but the same issue occurred.
Eventually, we reverted to git merge
, and the changes reappeared. This made us realize that git rebase
had caused the issue, but we didn’t know why.
The Realization
After searching online (including ChatGPT), I understood how rebase really works:
- Git finds the common ancestor between your branch and
origin/main
. - It removes your local commits (temporarily).
- It applies the new remote commits.
- Then it applies your local commits, one by one.
In contrast, git merge
brings in the remote branch all at once, preserving your branch as-is.
In other words, you may see that your commits are gone when you have more than one commit in your local branch!
Hello World!
Let's start blogging.