Remote repositories and teamwork

Что отвечать

`git fetch` pulls commits from the remote and updates the remote-tracking branches (for example `origin/main`), but **it does not move your local branch**. `git pull` is `git fetch` plus an immediate attempt to combine those commits with your local branch. By default it does this through a merge, which creates a merge commit when main and your branch have diverged. Many teams set `git config pull.rebase true` so that pull does fetch + rebase instead of merge, which keeps history cleaner.

Что хотят услышать

The candidate should: - say that fetch is safer: you see what arrived, then you decide on merge or rebase - explain that `pull --rebase` rebases **only your own local commits on top of the fresh remote**. It does not rewrite anyone else's remote commits. This is a common misconception. - name `git config --global pull.rebase true` as a sensible default, and `git config --global pull.ff only` as an even stricter option (fast-forward only, otherwise an error) - mention `git pull --autostash` for the case where you have uncommitted changes

Подводные камни

• ✗ Claiming that `pull --rebase` rewrites remote commits. In reality only your own local commits are replayed on top of the remote, and other people's commits are left untouched.
• ✗ Thinking `git pull` with no arguments always pulls the current branch. It needs a tracking branch, otherwise you have to run `git pull origin main`.
• ✗ Running `git pull` on top of a dirty working tree. The merge will fail, so stash first or use autostash.

Follow-up

• ? What does `git log HEAD..origin/main` show after a fetch?
• ? How does `pull.ff only` differ from `pull.rebase true`?
• ? How do you undo a botched `git pull`?

Что отвечать

A tracking branch is the link between a local branch and a remote branch. It is stored in `.git/config` as the block `[branch \"feature\"] remote = origin, merge = refs/heads/feature`. It gives you `git pull`/`git push` with no arguments, `git status` starts showing "ahead 2, behind 1", and you get the `@{upstream}` syntax (shorter: `@{u}`) for referring to the tracked remote branch: `git log @{u}..` shows your local commits that are not yet on the remote.

Что хотят услышать

A senior should: - name `git push -u origin feature` (or `--set-upstream`) as the way to set up tracking on the first push - say that `git switch -c feature origin/feature` creates a branch with tracking already configured - explain `@{u}` and `@{push}`. The first points to where you pull from, the second to where you push to (they often coincide, but in a triangular workflow they can differ). - mention `git branch --set-upstream-to origin/feature` for attaching tracking to an existing local branch - name `git fetch --prune` for removing tracking branches that no longer exist on the remote (after a PR is merged on the server)

Подводные камни

• ✗ Saying "a tracking branch appears automatically". It does not. You need `-u` on the first push.
• ✗ Thinking `git checkout feature` always creates tracking. It only does so when `origin/feature` exists and there is no local branch.
• ✗ Skipping `git fetch --prune`. Dead `origin/old-feature` refs pile up locally after PRs are merged.

Follow-up

• ? What does `git branch -vv` show?
• ? How does `@{push}` differ from `@{upstream}`?
• ? How do you set up tracking for an existing branch in one command?

Что отвечать

When you fork someone else's repo, `origin` is **your fork** (where you push your branches and PRs) and `upstream` is **the parent repo** (where you pull other people's changes from to stay in sync). You add it like this: `git remote add upstream <parent-url>`. Workflow: `git fetch upstream` -> `git rebase upstream/main` on your branch -> `git push origin feature`. This is a convention. The names `origin`/`upstream` are not reserved by Git, you can call them anything, but almost everyone uses these.

Что хотят услышать

A senior should: - say that the fork model is a triangular workflow: you read from one remote and write to another - name a concrete workflow: `git fetch upstream` + `git rebase upstream/main` (or merge) + push to your own origin + a PR into upstream - mention `git remote -v` as the way to look at all remotes and confirm that the push goes where it should - say that without upstream your fork goes stale fast and your PRs start to conflict with the current main - name `gh repo sync` as a handy shortcut through the GitHub CLI

Подводные камни

• ✗ Accidentally pushing into upstream instead of origin. Usually you lack the permissions, but if you are a maintainer of both, you will wipe out everyone else's main.
• ✗ Not setting up upstream at all. Your fork falls behind, your PRs conflict, and maintainers get annoyed.
• ✗ Confusing `upstream` as a remote (the name) with `upstream` as a tracking branch (`@{upstream}`). These are two different concepts under one word.

Follow-up

• ? What does `git remote -v` show in a forked repo after `git remote add upstream`?
• ? How do you sync a fork with upstream in one `gh` command?
• ? How does `origin` in a fork repo differ from `origin` in a regular clone?

Что отвечать

Acceptable: on your own feature branch after `git rebase main` or `git commit --amend`. You rewrote your own local commits and you are pushing the updated version. A disaster: on a shared branch (main, develop, release/*) where other developers depend on stable SHAs. A force-push to main wipes out the commits that landed there between your pushes, with no warning. The minimally safe option for a feature branch is `git push --force-with-lease`.

Что хотят услышать

A senior should: - name the concrete "you may" scenarios: after a rebase, amend, or squash of your own feature branch that nobody has based work on yet - say that on main / release branches a force-push must be blocked through GitHub/GitLab branch protection. Not through culture, through a technical guard. - explain `--force-with-lease`: the command refuses to push if the remote moved since your last fetch. This protects against clobbering commits that appeared between your fetch and push. - mention `--force-if-includes` (Git 2.30+) as an even stricter check. It accounts not just for the ref itself, but for whether it was fetched in your current session.

Подводные камни

• ✗ Saying "force-push is always bad". On your own feature branch after a rebase it is normal work.
• ✗ Relying on `--force-with-lease` as absolute protection. If a colleague did a fetch but did not pull it into their local branch, the lease will not see it.
• ✗ Force-pushing into main and assuming the server reflog will save you. On a bare repo the reflog is usually disabled.

Follow-up

• ? How does `--force-with-lease` differ from `--force-if-includes`?
• ? How do you forbid force-push to main through GitHub branch protection?
• ? What happens to CI on other branches after a force-push to main?

Что отвечать

Someone pushed to the same branch after your last fetch. Git protects the remote from your push "jumping" over their commits and losing them. The fix: `git fetch` -> look at what arrived with `git log HEAD..@{u}` -> `git rebase @{u}` (or `git pull --rebase`) -> resolve conflicts if any -> push again. No `--force` without understanding exactly what you are rewriting.

Что хотят услышать

The candidate should: - state the cause in one phrase: "the remote moved ahead, your push is not a fast-forward" - give the right workflow: fetch -> look at the diff -> rebase or merge -> push, without force as the first instinct - say that on a shared branch it is better to rebase your own commits on top of the fresh origin (cleaner history), while on a long-lived feature with several authors a merge is better (so you do not rewrite other people's SHAs) - mention that non-fast-forward is not a bug, it is a guard: if you force blindly, you wipe out other people's commits

Подводные камни

• ✗ Going straight to `git push --force`. You will wipe out what a colleague just pushed.
• ✗ Running `git pull` without `--rebase` on a feature branch. You get a merge commit out of nowhere in the PR.
• ✗ Not checking `git log HEAD..@{u}` before a merge/rebase. You will not understand what arrived.

Follow-up

• ? What does `git log HEAD..origin/main` show?
• ? Why is `git pull --rebase` better than `git pull` for a feature branch?
• ? How do you make `git push` push only the current branch by default?

Что отвечать

`clone` is a Git operation: it creates a local copy of the repo and configures `origin` to point at the source. On permissions: you can push to origin only if you have write access to that repo. `fork` is a GitHub/GitLab operation: it creates a server-side copy of the repo under your account (with your permissions), which you then clone to your machine. You need a fork when you do not have write to the source repo but you want to send PRs there.

Что хотят услышать

The candidate should: - distinguish "local copy" (clone) from "server-side copy under another account" (fork). These are two different levels. - say that on a team with direct access to the repo you do not need a fork, clone + branch-per-feature is enough - name fork as the standard for OSS: a maintainer does not give write to random contributors, so the contributor forks, pushes to their own fork, and opens a PR - mention `gh repo fork --clone` as a single command for fork+clone - say that fork and clone are independent: you can fork in the browser and not clone, and conversely you can clone someone else's repo without a fork

Подводные камни

• ✗ Forking when you already have write to the repo. You end up with two places to push to and get confused.
• ✗ Thinking fork is git fork. There is no such command, fork lives only in the hosting UI/CLI.
• ✗ Cloning a fork and not setting up upstream. You will not be able to pull updates from the parent repo.

Follow-up

• ? Which remotes do you get after `gh repo fork --clone <repo>`?
• ? What happens with a PR from a branch on your fork into upstream?
• ? When does a maintainer prefer to take a patch through push access versus a PR from a fork?