Remotes, pull requests and the daily team flow

Working alone, Git is a save button. In a team, it is a way to hand work to others safely. Screenings check that you understand the difference between fetch and pull, know how to push a branch, and can describe a pull request flow from start to merge. Here is that flow with the exact commands.

Remotes, fetch and pull

git clone https://example.com/team/app.git
git remote -v
git fetch origin
git pull --rebase origin main

origin is just the default name for the remote you cloned from. fetch downloads new commits and updates origin/main but changes nothing in your working files, so it is always safe. pull is fetch followed by a merge (or a rebase with --rebase). Use --rebase when your local commits are unpushed; it replays them on top of the new remote work and avoids noisy "Merge branch" commits.

The feature branch flow

git switch main
git pull
git switch -c fix/invoice-rounding
# edit, stage, commit
git push -u origin fix/invoice-rounding

Start from an updated main so your branch does not carry old code. -u links the local branch to the remote one, so later you type just git push. Open the pull request in your hosting tool. A review usually asks for changes; make them as new commits on the same branch and push again, and the pull request updates itself.

If main moves while you are working, bring your branch up to date before asking for review:

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

After a rebase the branch history has changed, so a plain push is refused. --force-with-lease overwrites only if nobody else has pushed to your branch, which is the safe form of force. Never force-push main or any shared branch.

Writing a pull request

A reviewer should understand the change in two minutes. Give the title the same care as a commit subject. In the description, write what problem it fixes, how to test it, and anything you are unsure about. Keep it small: one fix or one feature. If it took you a day, it will take a reviewer an hour; if it took a week, split it. After the merge, delete the branch locally with git branch -d fix/invoice-rounding.

Common mistakes and a practice habit

• Committing straight to main because "it is a small fix".
• Running git push --force instead of --force-with-lease, which can erase a colleague's commits.
• Letting a branch drift for weeks, then facing a wall of conflicts.
• Pull request descriptions that just say "see ticket".

Practice habit. Create a free repository, make a second clone in another folder and treat it as a colleague. Push a change from one clone, rebase the other on top of it, and resolve the result. Do this five times and fetch versus pull will stop being a trick question.