The Collaboration Loop

$ git fetch
  ...
$ git pull
  ...
$ git push
To ../bureau-central.git
   eabf8b3..eea5562  main -> main

Team git is three habits. Fetch before you believe any behind/ahead number (they compare your branch to your remote-tracking refs - your bookmarks). Integrate before you push - the everyday rejection is the remote protecting a teammate's commits; the fix is the routine loop, never force. And branch for every piece of work, so main only moves by deliberate, reviewed integrations.

$ git push --force-with-lease origin tiramisu-notes
To ../bureau-central.git
 + 05ce5fd...22c90fb tiramisu-notes -> tiramisu-notes (forced update)

When you DO rewrite - an amend on your own pushed branch - the honest update is --force-with-lease: overwrite only if the remote still matches your bookmark. Maria's lease on shared main bounced (stale info - the central copy had moved); the same lease on her own branch, whose state matched exactly, was accepted:

The pull request (GitLab: merge request - one object, two names) wraps this loop in a hosted conversation: push the branch, open the request, iterate under review - every further push updates it - then merge on the platform. The merge buttons are graph moves you already know: a weave, a squash into ONE new commit, or a replay. Squash and replay mint new commit ids, which is why a later plain git branch -d may refuse (-d proves the merge by ancestry; -D forces) - verify the content landed, then delete with -D.

After the platform merges: git switch main && git pull, then git fetch --prune to sweep bookmarks for branches that no longer exist. The loop closes where it began: a fresh branch for the next piece of work.

What the platform adds is conversation and policy - review, checks, protected branches. What it never adds is a new kind of history: every button is a move on the same beads and threads this course has drawn since chapter one. Trust the graph, and the collaboration is just mail between clones that agree on one central copy.