Skip to content

Git Level 4, Task 1: Clean History with git rebase

Today's task was an advanced lesson in maintaining a clean and linear project history. The scenario was common: I was working on a feature branch, but in the meantime, the master branch had moved forward with new updates. I needed to incorporate those updates into my branch.

Instead of using git merge, which would create a messy "merge commit" and non-linear history, I used git rebase. This powerful command essentially "re-plays" my feature branch commits on top of the latest master commit, making it look like I started my work after those updates were made. This document is my detailed, first-person guide to that process.

Table of Contents

The Task

My objective was to update a feature branch with the latest changes from the master branch using rebase. The requirements were: 1. Work within the /usr/src/kodekloudrepos/news Git repository on the Storage Server. 2. Rebase the feature branch onto the master branch. 3. Ensure no data is lost from the feature branch. 4. Avoid creating any "merge commit". 5. Push the updated feature branch to the remote server.

My Step-by-Step Solution

The process required switching to the correct branch and then executing the rebase command. As the repository was in a root-owned directory, all Git commands required sudo.

Phase 1: Preparation

  1. I connected to the Storage Server (ssh natasha@ststor01) and navigated to the repository (cd /usr/src/kodekloudrepos/news).
  2. Crucially, I switched to the feature branch. You always rebase the branch you are working on (feature) onto the target branch (master). 
    sudo git checkout feature

Phase 2: The Rebase

  1. I executed the main command to rebase my current branch (feature) onto master. 
    sudo git rebase master
    Git rewound my commits, pulled in the new commits from master, and then re-applied my commits one by one on top.

Phase 3: Pushing the Changes

  1. After a rebase, the history of the feature branch has completely changed. If I tried a normal git push, it would be rejected because my local history no longer matches the remote history. I had to use force push to update the remote. 
    sudo git push origin feature --force
    This successfully updated the remote feature branch with the new, linear history.

Why Did I Do This? (The "What & Why")

  • git rebase: This command is an alternative to git merge. It integrates changes from one branch into another.

  • Linear History: This is the main reason to use rebase. By moving my feature branch to begin at the tip of the master branch, I create a straight line of history. This makes it much easier to read logs (git log) and understand the timeline of changes compared to the "railroad tracks" created by frequent merging.

  • Avoiding "Merge Commits": A standard git merge master creates a special commit just to tie the two histories together. These commits add noise to the history without adding any actual code changes. git rebase avoids this entirely.

Deep Dive: git merge vs. git rebase

This task highlighted the fundamental difference between the two integration strategies.

git merge master (The "Safe" Way):

  • What it does: Creates a new commit (M) that has two parents: the tip of feature and the tip of master.
  • Pros: It preserves the exact history of when commits happened. It is non-destructive.
  • Cons: History can become cluttered with merge commits. The graph becomes complex and hard to read.

git rebase master (The "Clean" Way - Used Here):

  • What it does: It lifts the commits from the feature branch and plants them onto the new tip of master. It essentially rewrites history to say, "I started this work today, not last week."

  • Pros: Creates a perfectly linear history. No extra merge commits.

  • Cons: It creates new commits (new hashes) for the existing work. Rule of Thumb: Never rebase a branch that other people are also working on, because it rewrites history they depend on. Since I was the only one working on feature, it was safe.

Common Pitfalls

  • Rebasing in the Wrong Direction: Running git checkout master followed by git rebase feature would be a disaster. It would rewrite the master branch history to be on top of feature, which is almost never what you want. Always checkout the feature branch first.

  • Merge Conflicts: Just like a merge, a rebase can have conflicts. If master changed a line that I also changed in feature, Git will pause the rebase and ask me to fix it. I would fix the file, git add it, and then run git rebase --continue (not git commit).

  • Forgetting to Force Push: Since rebase rewrites history, the local branch and remote branch have diverged. A normal git push will fail. You must use --force (or --force-with-lease for safety) to overwrite the remote branch.

Exploring the Commands I Used

  • sudo git checkout feature: Switched to the branch I wanted to update.

  • sudo git rebase master: The command to "lift and shift" the current branch (feature) onto the tip of the target branch (master).

  • sudo git push origin feature --force: The command to update the remote server. The --force flag is mandatory after a rebase because the commit history has been rewritten.