Day 32: Git Rebase | 100 Days of DevOps
Content:
Today I worked on rebasing a feature branch with the master branch in a Git repository. The objective was to integrate the latest changes from the master branch into the feature branch without creating a merge commit and while preserving all feature work.
🔹 What I Learned
- What
git rebasedoes and how it differs from merge - How to reapply feature branch commits on top of another branch
- Why rebasing keeps a clean and linear commit history
- When to use
git push --forceafter rewriting history
Steps I Followed
1. Connected to Storage Server
ssh natasha@ststor01
2. Switched to Root User
sudo su
3. Navigated to the Repository
cd /usr/src/kodekloudrepos/beta
4. Checked Current Branches
git branch
Observed:
feature(current branch)master
5. Rebased Feature Branch with Master
git rebase master
This successfully replayed the feature branch commits on top of the latest master branch.
6. Verified Commit History
git log --oneline --graph
Confirmed:
- Feature commit is on top of master
- No merge commits were created
- History is linear
7. Pushed Changes to Remote Repository
git push origin feature --force
Force push was required because rebase rewrites commit history.
8. Verified Final History
git log --graph --decorate --all
Confirmed clean structure:
master→ base commitsfeature→ rebased commit on top
🔹 My Understanding
This task helped me understand how rebasing works by moving feature branch commits onto the latest base branch instead of merging. It ensures a clean project history, making it easier to read and maintain. I also learned that force pushing is necessary after a rebase since commit history changes.
🔹 What I Found Interesting
I found it interesting that rebasing rewrites commit history in such a clean way, making it look like the feature work was built directly on top of the latest code. Compared to merging, it avoids unnecessary merge commits and keeps the repository history simple and organized.
📌 Full notes: GitHub link