Skip to content

Summary: Remotes and forks

A remote is a named pointer to another git repository’s URL. Branches travel between machines via push and pull through remotes.

Terminal window
git clone <url> # get a full copy of a remote repo
git remote -v # see your remotes
git remote add upstream <url> # add a second remote
git fetch # download remote changes without merging
git pull --rebase # fetch + rebase (no merge commit)
git push # send your commits up
git push -u origin <branch> # first push of a new branch (sets tracking)
git push --force-with-lease # safe force-push for personal branches
  • Every clone is a full repo
  • Local operations work offline
  • GitHub outage doesn’t lose data; only blocks push/pull
  • Recovery is possible from any clone
Terminal window
git config --global pull.rebase true

Set this once. Stops the merge-commit clutter on every pull.

PointerPoints to
originYour fork
upstreamThe original project

Push to origin. Open PR from origin to upstream. Sync origin/main from upstream/main to stay current.

  • Yes: --force-with-lease on your own personal branches (after rebase)
  • No: --force (plain) on anything; too dangerous
  • No: any force-push on main, develop, or release branches

origin/main, origin/feature-x are read-only labels for “what the remote looked like at last fetch.” git status tells you ahead / behind / diverged.

You have:

  • Branches (L5)
  • PRs (L6)
  • Conflicts (L7)
  • Remotes (L8)

That is confident two-person collaboration. Phase 3 covers production team workflows.

The push/pull/remote skills are the foundation for every team workflow Phase 3 introduces. GitHub Flow, GitFlow, Trunk-based are all conventions BUILT on remotes and branches. You have the primitives; Phase 3 teaches the patterns that wrap them.

Git stores snapshots. Every other command is just navigating those snapshots.

Push and pull are navigating snapshots between machines.