GitLab Git Associate: Remote collaboration

This domain tests remotes, remote-tracking branches, and the fetch/pull/push cycle, plus how GitLab merge requests fit around Git commands. Questions often hinge on what a command changes locally versus on the server.

Remotes and remote-tracking refs

• git clone creates origin; git remote add and git remote -v manage names and URLs.
• origin/main is a remote-tracking ref updated by fetch. It is not the server's live state.
• git fetch downloads missing objects and updates remote-tracking refs; it does not change your working tree or local branches.
• git pull is fetch plus integration: merge by default, rebase with --rebase or pull.rebase=true.
• git push -u origin feature sets the upstream, so later git push knows where to go.

Pushing and rejection

A push updates a remote ref and is accepted only if it is a fast-forward, unless forced. A non-fast-forward rejection means the remote has commits you lack. --force-with-lease refuses to overwrite if the remote moved since your last fetch, unlike plain --force.

Merge requests

A GitLab merge request is a review object requesting that a source branch be merged into a target branch. It carries discussion, approvals, and pipeline status; it is not a Git object. For fork workflows, the source branch lives in the fork and the target in the upstream project.

Worked example

You branch from origin/main alongside a teammate. The teammate pushes first; your push is rejected. Run git fetch origin, inspect with git log --oneline main..origin/main, then git rebase origin/main (or merge), resolve any conflicts, and push. Forcing would erase the teammate's commit from the shared branch, so it is the wrong fix.

Traps that cost marks

• Thinking git fetch updates your files; it only updates remote-tracking refs.
• Treating a pull request or merge request as a Git command.
• Force-pushing a shared branch and rewriting history others depend on.
• Assuming origin/main updates automatically after someone else pushes.