5 exercises on talking to remotes the native way: fetch, pull, push to origin, set the upstream, force-push, pull requests, and cloning a repo.
Key patterns
fetch (download, no merge) vs pull (fetch + merge)
push to origin; set the upstream on first push
track a remote branch / upstream branch
force-push — prefer --force-with-lease
open a pull request; clone a repo (once)
0 / 5 completed
1 / 5
You want to download the latest commits from the remote without changing your working files or merging anything. Which command verb is correct?
Fetch — download remote changes without merging:
git fetch updates your remote-tracking branches (e.g. origin/main) but leaves your working branch untouched. git pull is essentially fetch + merge (or fetch + rebase) in one step.
Remote sync collocations:
fetch from origin → download new commits, no merge
pull from origin → fetch and integrate into your branch
push to origin → upload your local commits
clone a repo → create a full local copy of a remote (done once)
Why not the others?Pull would also merge; clone creates a brand-new local repo (you only clone once); checkout switches branches/files locally. Only fetch downloads without touching your work.
2 / 5
A teammate set up a brand-new local branch and now wants their first push to also tell Git which remote branch it should track. The standard phrase is to:
Set the upstream — establish the remote tracking branch:
On a first push you run git push -u origin my-branch (or --set-upstream). This makes your local branch trackorigin/my-branch, so future git push / git pull need no arguments.
Tracking vocabulary:
set the upstream → tie a local branch to a remote branch
track a remote branch → the local branch follows the remote
upstream branch → the remote branch your local one tracks
tracking branch → the local branch doing the tracking
Why not the rest? Git uses upstream, never "downstream", for this. "Bind the origin" and "link the head" are invented — the fixed term is set the upstream.
3 / 5
You rebased your branch, which rewrote its commit hashes. Your normal git push is now rejected because histories diverged. The safest way to overwrite the remote is to:
Force-push — overwrite remote history after a rewrite:
After a rebase or amend, the remote branch’s history no longer matches yours, so a normal push is rejected. You force-push to overwrite it. Prefer --force-with-lease over plain --force: it refuses to overwrite if someone else pushed in the meantime, protecting their work.
Force-push vocabulary:
force-push → overwrite the remote branch (git push --force)
force-push with lease → safer variant (--force-with-lease)
diverged histories → local and remote share no straight line
rejected push → "Updates were rejected" error
Why not the rest?--hard belongs to git reset, not push; --overwrite and --again are not real flags. The term is force-push.
4 / 5
On GitHub/GitLab, the unit of work you open to propose merging your branch — where reviewers comment and approve — is called a:
Pull request — the proposal-to-merge unit:
A pull request (PR, GitHub) — called a merge request (MR) on GitLab — is where you ask maintainers to review and merge your branch. You open, review, approve, and merge a PR.
PR collocations:
open / raise a pull request → create the proposal
open a PR against main → "against" names the target branch
request changes / approve → review verdicts
merge / close a PR → accept or drop it
Why not the rest? "Merge ticket", "push request" and "review branch" are not real terms. The established pair is pull request (GitHub) / merge request (GitLab).
5 / 5
A new joiner needs a complete local copy of the company’s repository for the first time. The correct verb is:
"___ the repo and run npm install."
Clone the repo — make the initial local copy:
git clone <url> creates a full local copy of a remote repository, including all history and branches, and automatically names the remote origin and sets up tracking. You clone once; afterwards you pull and push.
Repo-setup collocations:
clone a repo → first-time full local copy
fork a repo → make your own server-side copy to contribute back
add a remote → register another remote (e.g. upstream)
shallow clone → --depth 1, history-truncated for speed
Why not the rest? "Copy/download the repo" misses the Git semantics; you pull only after a clone exists. The right verb for the first full copy is clone.