Git · Lesson 5 of 6

Pull requests & teamwork

The feature-branch workflow, pull requests and code review.

Most teams follow a feature-branch workflow:

Pull the latest main.
Create a branch for one task (often named after the ticket: feature/JOB-142-filter).
Commit in small steps and push the branch.
Open a pull request (PR) on GitHub describing what changed and how to test it.
Teammates review, comment and approve; automated checks (CI) run tests.
Merge into main and delete the branch.

Good PRs are small, focused and explain the why. When reviewing, be specific and kind: suggest, don't command.

Example in the terminal

Run these on your own computer

$ git switch main
$ git pull
$ git switch -c feature/JOB-142-salary-filter

# ...edit, test...
$ git add .
$ git commit -m "Filter jobs by salary range (JOB-142)"
$ git push -u origin feature/JOB-142-salary-filter
remote: Create a pull request for 'feature/JOB-142-salary-filter' on GitHub by visiting:
remote:   https://github.com/anu-kumar/job-tracker/pull/new/feature/JOB-142-salary-filter

Lines starting with $ are commands you type; the rest is what Git prints. Names and URLs are examples.

Key points

Start from an up-to-date main.
One task per branch and PR.
Describe what and why; keep PRs small.

Quick check

What is a pull request?

A command that downloads code A request to review and merge a branch A way to delete a repository A Git configuration file

Practice task

Open a pull request on your own repo from a feature branch, add a description with test steps, then merge it on GitHub.

Interview corner

How do you keep a long-running branch up to date with main?

Regularly merge main into it (or rebase onto main if the branch is private), resolving conflicts early while they're small.

What do you look for when reviewing a PR?

Correctness, readable naming, tests for the change, edge cases, security issues, and whether the change does only what the description says.