Have you ever entered a number into a Python program but received an error when trying to perform a calculation? This is a common problem for beginners. It often happens because the data type of a value is different from what the program expects. For example, when you use Python's input() function, the value entered by the user is returned as a string. If you want to perform mathematical calculations with that value, you may need to convert it into a numeric type first. This process is called type conversion . In this article, we will learn what type conversion is, why it is useful, how to convert values using int() , float() , str() , and bool() , and how to avoid common errors. 1. What Is Type Conversion in Python? Type conversion is the process of converting a value from one data type to another. For example, you may convert: A string into an integer. An integer into a floating-point number. A number into a string. A value into a Boolean value. Consider this example: number = ...
In the previous article, you learned how to combine branches using git merge. Merging preserves the complete branching history, which is useful because it shows exactly how development happened.
However, sometimes developers prefer a cleaner and more linear commit history.
Instead of creating a merge commit, Git provides another powerful command:
git rebase
The git rebase command takes the commits from one branch and replays them on top of another branch, making the project history appear as though the work happened in a straight line.
Because git rebase rewrites commit history, it is a powerful command that should be used with care.
In this article, you will learn:
What
git rebaseisWhy developers use rebase
How rebase works
Rebase vs Merge
Interactive rebase
Resolving conflicts during a rebase
When to use rebase
When to avoid rebase
Best practices
By the end of this article, you'll understand how rebase creates a cleaner project history and when it is appropriate to use it.
What is Git Rebase?
Git Rebase moves or reapplies commits from one branch onto another base commit.
Instead of joining two branches with a merge commit, Git takes each commit from your current branch and replays it on top of the latest commit of the target branch.
This results in a linear commit history.
Why Do We Need Rebase?
Suppose your repository looks like this:
main
↓
Commit A
↓
Commit B
Now you create a new branch:
feature-login
While you're working, another developer adds new commits to main.
Repository:
main
↓
Commit A
↓
Commit B
↓
Commit C
↓
Commit D
Meanwhile:
feature-login
↓
Commit X
↓
Commit Y
Now your branch is behind main.
Instead of merging, you can rebase your branch onto the latest main.
Visual Representation Before Rebase
A──B──C──D (main)
\
X──Y (feature-login)
Running Rebase
First, switch to the feature branch:
git switch feature-login
Now run:
git rebase main
Git performs the following steps:
Temporarily removes commits
XandY.Moves the branch to the latest commit (
D).Reapplies
X.Reapplies
Y.
Repository After Rebase
A──B──C──D──X'──Y'
Notice something interesting.
The commits now appear after D.
Git actually creates new versions of the commits (X' and Y') because they have a different parent commit.
This is why rebase rewrites history.
Understanding "Replaying Commits"
Imagine writing two paragraphs in a notebook.
Later, someone adds four pages before your paragraphs.
Instead of inserting arrows and notes, you copy your paragraphs and rewrite them after the new pages.
That is similar to how Git rebase works.
Rebase vs Merge
Suppose we have this history:
A──B──C (main)
\
X──Y (feature)
Merge
A──B──C────────M
\ /
X──────Y
A merge commit (M) is created.
Rebase
A──B──C──X'──Y'
No merge commit is created.
The history becomes linear.
Advantages of Rebase
A linear history offers several benefits:
Easier to read.
Cleaner commit graph.
Simpler debugging with tools like
git bisect.Reduced number of unnecessary merge commits.
Better organization of project history.
Does Rebase Change My Code?
Usually, no.
The final project content is generally the same as it would be after a merge.
What changes is how the history is recorded.
Rebase May Cause Conflicts
Suppose:
main
changes:
System.out.println("Welcome Student");
Your feature branch changes:
System.out.println("Welcome User");
During rebase, Git may stop and report a conflict.
Example:
CONFLICT (content): Merge conflict in Login.java
The conflict is resolved in a similar way to a merge conflict.
Continuing After Resolving a Conflict
After editing the file and removing the conflict markers:
Stage the resolved file:
git add Login.java
Continue the rebase:
git rebase --continue
Git proceeds with the remaining commits.
Skipping a Commit
Sometimes a particular commit is no longer needed.
You can skip it:
git rebase --skip
Git ignores the current commit and continues rebasing the rest.
Use this carefully because skipped changes are not applied.
Aborting a Rebase
If you decide not to continue:
git rebase --abort
Git attempts to restore your branch to the state it was in before the rebase began.
Interactive Rebase
One of Git's most powerful features is:
git rebase -i HEAD~3
This opens an editor listing the last three commits.
Example:
pick 5c21d4 Add login page
pick 3f82ab Fix login bug
pick 8b67e1 Improve validation
You can now:
Reorder commits.
Edit commit messages.
Combine commits.
Remove unnecessary commits.
This is extremely useful for cleaning up your work before sharing it.
Squashing Commits
Suppose your history is:
Add Login
↓
Fix Typo
↓
Fix Another Typo
↓
Fix Small Bug
Instead of four small commits, you may prefer one meaningful commit:
Implement Login Feature
Interactive rebase allows you to squash multiple commits into one.
This produces a cleaner and more understandable project history.
When Should You Use Rebase?
Rebase is commonly used when:
Updating a feature branch with the latest changes from
main.Cleaning up local commits before opening a pull request.
Creating a linear commit history.
Organizing commits before sharing them.
When Should You Avoid Rebase?
A widely accepted guideline is:
Do not rebase commits that have already been shared with others.
Because rebase rewrites commit history, it changes commit IDs.
If other developers have based work on the original commits, rewriting that history can make collaboration difficult.
For shared branches, merging is often the safer choice.
Real-World Example
Suppose you are working on:
feature-payment
While you are developing, the main branch receives:
Security fixes
Performance improvements
Bug fixes
Before creating a pull request, you update your branch:
git switch feature-payment
git rebase main
Now your work sits on top of the latest version of the project.
Merge vs Rebase Comparison
| Merge | Rebase |
|---|---|
| Preserves branch history | Rewrites commit history |
| Creates a merge commit (except fast-forward merges) | Usually produces a linear history without a merge commit |
| Safer for shared branches | Best for cleaning up local history |
| Shows exactly how development occurred | Produces a cleaner commit graph |
Common Beginner Mistakes
Mistake 1
Rebasing a branch that has already been pushed and shared.
This can confuse collaborators because commit IDs change.
Mistake 2
Ignoring conflicts during a rebase.
Always resolve each conflict carefully before continuing.
Mistake 3
Thinking rebase deletes commits.
It usually creates new versions of the commits with different parent relationships.
Mistake 4
Using interactive rebase without understanding each option.
Practice on small personal repositories before using it in important projects.
Best Practices
Rebase local feature branches before merging them.
Use interactive rebase to clean up commit history.
Avoid rebasing public/shared branches.
Resolve conflicts carefully.
Test your application after completing a rebase.
Create meaningful commits before sharing your work.
Useful Rebase Commands
| Command | Purpose |
|---|---|
git rebase main | Rebase the current branch onto main |
git rebase --continue | Continue after resolving conflicts |
git rebase --abort | Cancel the rebase |
git rebase --skip | Skip the current commit |
git rebase -i HEAD~3 | Interactively edit the last three commits |
Summary
Git Rebase is a powerful command that creates a clean, linear commit history by replaying commits onto a new base. Unlike git merge, which preserves the branching structure, rebase rewrites commit history to make it appear as though the work was developed in sequence.
While rebase improves readability and helps organize local commits, it should be used carefully because it changes commit IDs. As a general rule, use rebase for your own local work and avoid rebasing commits that have already been shared with others.
Understanding both merge and rebase allows you to choose the workflow that best fits your project and your team's collaboration style.
Comments
Post a Comment