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:

  1. Git finds the common ancestor between your branch and origin/main.
  2. It removes your local commits (temporarily).
  3. It applies the new remote commits.
  4. 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.