Git Merge VS Git Rebase
Which we should choose and why?
Git Merge
Workflow
When you use git merge you are essentially creating a new merge commit that combines the changes from one branch (the source branch) into another branch (the target branch)
Command
git merge feature main
Detailed Command
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
[--[no-]allow-unrelated-histories]
[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
[--into-name <branch>] [<commit>…]
git merge (--continue | --abort | --quit)Commit History
The commit history remains linear and retains a clear timeline of when each branch was merged into the target branch. Merge commits show when and where the branches were integrated
Advantages
- Preserves the commit history of both branches
- Maintain a clean record of when and where the integration occurred
- Generally easier to understand for collaboration and open source projects.
- Merge is simple and straightforward
- Merge maintain the branch context
Drawbacks
- Merge isn’t user-friendly
- Merge’s exhaustive nature in clumsy history and log
- Merge’s git log must be constantly and properly maintained, or devolve into a mess
Use Case
Recommended for long-lived feature branches or when you want to maintain a history of all changes in the branch
Git Rebase
Workflow
When you use git rebase, you move or replay the entire commit history of one branch onto another branch. This effectively “rewrites” the commit history of the source branch on top of the target branch.
Command
git rebase main
Detailed Command
git rebase [-i | --interactive] [<options>] [--exec <cmd>]
[--onto <newbase> | --keep-base] [<upstream> [<branch>]]
git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
--root [<branch>]
git rebase (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)Commit History
The commit history becomes linear and it appears as if the changes in the source branch were made directly on top of the target branch creating a cleaner, more linear history.
Advantages
- Create a linear commit history that can be easier to follow.
- Eliminates unnecessary merge commits. Resulting in a cleaner and more linear commit history.
Drawbacks
- Users can’t track how and when commits were merged on the target branch
- Rebase won’t work with pull requests since you can't see minor changes someone else made.
- Rebase makes you resolve conflict in the order they were created to continue the rebase. Unfortunately, this means more work for you as you may need to fix the same conflict again and again.
- Rebase lowers the feature down to the small number of commits, making it challenging to see the context.
Use Case
- Recommended for short-lived feature branches or bug fixes branch
- Useful when you want to maintain a clean, linear history without merge commit.
- Works well for keeping a feature branch up to date with changes in the main branch.
You can use git rebase to work on private branch. Then do git merge to bring together into on coherent timeline. by this you can use rebase and merge together
Difference between Merge and Rebase
Diagram of Working
Base
Merge
Rebase
Some Consideration
# Shared Branch: If you are working in a shared repository where multiple developers are working on the same branches. “merge” is generally safer and more appropriate because it preserves the commit history of each developer
# Private Branch: If you are working on your own feature branch and want to maintain a clean and linear commit history, or if you want to keep your branch up to date with changes in the main branch “rebase” can be a good choice.
# Caution with Rebasing: Be cautious when using rebase on branches that others working on because it rewrites commit history. Rebasing should be used for personal branches or when you are sure it won't disturb collaboration.
