Rebase, Merge, Pull, and Working with Remotes—Simplified
Understanding Remotes in Git
In Git, a remote is any repository other than your local one. It can be:
origin
: The remote repo you cloned fromupstream
: The original repo you forked from (not cloned)
đź’ˇ Use
git remote -v
orgit remote -vv
to view current remotes.
Setting a New Remote
git remote add
Use a short, memorable name (like origin
or upstream
) so you don’t need to type the full URL every time.
Using git diff
to Compare Branches
The git diff
command shows the differences between your current branch and another branch (local or remote).
git diff <branch-name>
git diff <remote-name>/<branch-name>
Git Merge vs Pull vs Rebase
1. git merge
Merges the source branch into your current branch, creating a special “merge commit”.
Example Scenario:
- Source branch:
master
→ Commits: A, B, C, D, E - Current branch:
feature
→ Commits: A, B, C, F
bashCopyEditgit merge origin/master
# or for local:
git merge . master
Resulting History (after merge):
cssCopyEditA → B → C → merge-commit → F
Commits D and E are merged, but not shown as individual entries.
Merge Conflict Handling:
bashCopyEdit# Abort a merge if conflicts arise
git merge --abort
# After resolving conflicts manually:
git merge --continue
2. git pull
git pull
= git fetch
+ git merge
It pulls changes from a remote branch and merges them into your current branch, creating a merge commit.
bashCopyEditgit pull origin master
# or
git pull . master
Same history as git merge
, with an extra merge commit.
3. git rebase
Rewrites your current branch’s history by applying your commits on top of another branch.
bashCopyEditgit rebase master
# or rebase from a remote:
git rebase upstream/f-Alerts
Always run
git fetch upstream
before rebasing from a remote.
Resulting History:
mathematicaCopyEditA → B → C → D → E → F
No merge commit—clean linear history.
Rebase Conflict Handling:
bashCopyEdit# After resolving conflict
git rebase --continue
# To abort rebase
git rebase --abort
When Should You Use What?
Use git rebase
when:
- You’re ready to merge your feature branch into the base branch
- You want a clean, linear history with no extra merge commits
Use git merge
or git pull
when:
- You’re pulling updates from the base branch into your feature branch
- You don’t need all the intermediate commit history of the base branch repeated in your feature
Summary
Command | Use Case | Creates Merge Commit? | Rewrites History? |
---|---|---|---|
git merge | Integrating changes from another branch | Yes | No |
git pull | Fetch and merge from remote | Yes | No |
git rebase | Apply commits from another branch cleanly | No | Yes |
Pro Tips
- Always run
git fetch
before merging or rebasing from a remote - Use rebase in feature branches for clean merges
- Prefer merge or pull when syncing from base to feature (to avoid unnecessary complexity)