Syncing with Remote (Push & Pull)

19.1 What Syncing Really Means

Syncing involves three locations:
Working Directory - your current files
Local Repository - your committed history
Remote Repository - GitHub (or other remote)
Push and pull move commits between local and remote, not raw files.

19.2 Pushing Changes to Remote

Push sends your local commits to the remote branch.
1git push

First-time push (if upstream not set):
1git push -u origin main

After that, simple pushes work:
1git push

19.3 Pulling Changes from Remote

Pull fetches commits from the remote and merges them into your current branch.
1git pull

Under the hood:
1git pull = git fetch + git merge

This means it can create merge commits if histories diverge.

19.4 Fetch vs Pull (Important Distinction)

Fetch
1git fetch
Downloads remote changes
Does not modify your working directory
Safe for inspection

Pull
1git pull
Fetches and merges immediately
Can cause conflicts

Best practice in teams:
Fetch first, then merge manually

19.5 Pull with Rebase

To keep a clean history:
1git pull --rebase

This:
Replays your commits on top of remote commits
Avoids merge commits
Produces a linear history
Common team standard.

19.6 Syncing a Specific Branch

Push a specific branch:
1git push origin feature/login

Pull a specific branch:
1git pull origin develop

19.7 Handling Push Rejections

If your push is rejected:
1! [rejected] main -> main (fetch first)

Fix:
1git pull --rebase 2git push

This updates your local branch before pushing.

19.8 Best Practices

Pull before starting new work
Push small, meaningful commits
Avoid pushing broken code to shared branches
Use pull --rebase for clean history
Never force push to shared branches

19.9 Key Takeaways

Push sends commits to the remote; pull brings commits from it.
git pull = fetch + merge; git fetch is safer for inspection.
Use git pull --rebase to avoid unnecessary merge commits.
Push rejections mean the remote has newer commits—pull first.
Sync often to reduce conflicts and improve collaboration.