Git Remotes and Collaboration: Fetch, Pull, Push, and PR Flow

Once branching makes sense locally, the next challenge is collaboration. Remotes are where your local history meets your team’s shared history.

Table of Contents

This post explains how to synchronize local and remote history safely.

Remote Basics

Syncing History

Team Workflow

Series Navigation

Remote basics

What a remote is

A remote is a named reference to another Git repository, usually on a hosting platform. The default remote from git clone is typically named origin.

List remotes:

git remote -v

Add a remote manually in an existing repository:

git remote add origin https://example.com/org/project.git

Inspect remotes and tracking branches

Git stores remote-tracking refs like origin/main. These are your local view of remote state after fetch/pull.

Useful commands:

git branch -vv
git log --oneline --decorate --graph --all

git branch -vv shows each local branch and whether it is ahead/behind its upstream branch.

Syncing history

Fetch vs pull

git fetch downloads remote changes but does not modify your current branch.

git fetch origin

git pull is shorthand for:

  1. git fetch
  2. plus either git merge or git rebase into your current branch

If you want more control, use fetch first, inspect, then integrate intentionally.

Compare local and remote before integrating:

git log --oneline --left-right --graph HEAD...origin/main

Push and upstream tracking

Push a new local branch and set upstream in one command:

git push -u origin feature/login-audit

After this, git push and git pull on that branch know the default remote target automatically.

If your push is rejected because remote history moved, fetch first and integrate before retrying.

Pull with merge vs pull with rebase

Default pull often creates merge commits in feature branches. Some teams prefer rebasing to keep a linear history.

Merge-style pull:

git pull

Rebase-style pull:

git pull --rebase

Rule of thumb:

  • Use rebase on your personal feature branches for cleaner history
  • Avoid rewriting shared branch history that others already depend on

Team workflow

A practical PR sequence

This sequence works in most hosted Git platforms:

git switch main
git pull --ff-only
git switch -c feature/session-timeout

# ...make focused commits...

git push -u origin feature/session-timeout

Then open a pull request from feature/session-timeout into main in your Git hosting UI.

Before merging, keep your branch current:

git fetch origin
git rebase origin/main
git push --force-with-lease

--force-with-lease is safer than --force because it refuses to overwrite remote updates you have not seen.

Force-push rules

Good default team policy:

  • Never force-push main (or any protected shared branch)
  • Force-push only your own feature branch when rebasing
  • Prefer --force-with-lease over --force

This keeps collaboration safe while still allowing tidy commit history on feature branches.

Collaboration troubleshooting checklist

  • Push rejected? git fetch and inspect divergence first
  • Unexpected local merge commit? Check your pull strategy
  • Unsure where your branch points? Run git branch -vv
  • Nervous about history rewrites? Create a safety branch before rebasing

Next in this series

In the next post, we go deeper into history editing and recovery: amend, interactive rebase, cherry-pick, and reflog rescue patterns