Working Like an Engineer: Git, PRs & Code Review · Lesson 1 of 6 · Bonus module

The Loop: Branch, Commit, PR, Merge

Code doesn't go from your laptop to production. It goes through a loop every company runs. Learn it once and every team feels familiar.

By Shahriyar · Updated

The loop, start to finish

  1. Update main, then branch off it — named for the work, not for you.
  2. Small commits as you go. Each one a step that makes sense on its own.
  3. Push and open a PR. The description says what changed and why.
  4. Review happens. Comments, maybe "changes requested". You respond and re-push.
  5. Approval → merge (often squashed into one commit) → the branch is deleted.
▸ The whole loop in commands
git checkout main && git pull
git checkout -b test/checkout-smoke
# ...work...
git add -p                        # stage in reviewable pieces
git commit -m "Add smoke tests for guest checkout"
git push -u origin test/checkout-smoke
# then open the PR in the browser

Who approves, and what blocks

On a real repo the merge button is locked until the rules pass: one or two approvals, and CI green. Nobody merges by permission of politeness — the branch protection does the enforcing. That's why a red pipeline on your PR is everyone's business.

Grounded in the git documentation and GitHub's pull request flow

All lessons in Working Like an Engineer: Git, PRs & Code Review

  1. The Loop: Branch, Commit, PR, Merge
  2. Your First Merge Conflict
  3. Reading Code You Didn't Write
  4. Receiving a Review Without Taking It Personally
  5. Giving a Review as the Quality Person
  6. Commits and PRs an Interviewer Will Read