The merge operation is basically a commit that takes changes from one branch and merges them into another. Simple as that.
Commonly used when developing new features covering most if not all chiefly known branching strategies as they are following the branch-per-feature model. Each branch representing a new feature where once developed will be merged back to the base branch being
To merge the
abc-feature branch to
git checkout main git fetch && git pull git merge abc-feature
- Preserves the Git history.
- Clumsy logs, not so easy to navigate.
The rebase operation moves all commits from the current branch onto a new base commit. A base commit is the initial commit that branches are created from.
To rebase changes on
abc-feature branch from
git checkout abc-feature git fetch && git pull git rebase main git checkout main git merge abc-feature
git rebase mainupdates abc-feature’s base commit to point to main.
- Merging after rebase is required since the rebase involves “moving” of commits. At the end of the day, you still need to merge before pushing to remote.
- Git logs are linear. Easy to navigate.
- Prevent bugs and spares you from resolving conflicts and a possible rework.
- You cannot track how and when the commits were merged hence Git history not being preserved at all.
mergea single commit where
rebaseinvolves whatever number of commits are being included in the current branch.
mergecreates a merge-commit.
rebaseonly “relocate” commits.
mergepreserves history as
In case of doubt, use
merge. In fact, always use
merge. The Git history could look as clumsy as it could get, but at least it’s preserved. And that’s the hill I’m willing to die on.