Why branch at all, when you could just push to main
Because a branch is a safe sandbox and a pull request is a checkpoint. Session 1 told you branches are cheap pointers; this session spends them freely. You will create a branch, push it, open a PR from the terminal, and review a teammate's PR both as commenter and approver. The payoff is trunk-based development: main stays always-deployable while all the messy work happens on short-lived branches that only merge once reviewed and green.
git switch -c and pushed, your first pull request opened entirely from the terminal with gh pr create --fill, hands-on time on the reviewer side (gh pr review, comments, suggestions, approve), and a CODEOWNERS file that auto-requests the right reviewer for every path.
Branch and switch from the terminal 5 min live
The modern command for this is git switch - clearer than the old overloaded git checkout. One flag creates a branch and moves you onto it in a single step. Remember from Session 1: a branch is just a movable pointer, so making one is instant and costs nothing.
Liveswitch -c, work, push -u - the branch loop3 min▶
git switch -c feature/add-docscreates the branch and moves HEAD onto it in one step. Everything you commit now lands on the feature branch, leaving main untouched.- Name branches so the intent is obvious. Conventions like
feature/,fix/,docs/prefixes group work and read well ingit branch.feature/add-usage-docsbeatsmy-changes. git push -u origin feature/add-docspublishes the branch to GitHub and sets upstream, so later justgit push. This is what makes a PR possible - GitHub needs the branch before it can open one.- Keep the branch current. While you work, main moves on. Freshen up with
git pull origin main(a merge) or rebase onto it - Session 4 goes deep on the difference. For now: pull main in often so the eventual merge is small.
Self-studyswitch vs the old checkout2 min read▶
You will still see git checkout everywhere online. It works, but it does two unrelated jobs - switching branches and restoring files - which caused years of confusion. Modern git split it: git switch changes branches, git restore (Session 2) restores files. Use the new pair; recognize the old one in other people's docs.
| Goal | Modern | Old |
|---|---|---|
| New branch + move to it | git switch -c name | git checkout -b name |
| Move to existing branch | git switch name | git checkout name |
| Discard file changes | git restore file | git checkout -- file |
PRs without leaving the terminal (gh) 5 min live
The pull request is still the GitHub proposal object you met in the non-tech track: "here is my branch, please review and merge it." What changes here is you never touch the browser. gh opens it, fills it, and tracks it from where you already are - the terminal.
Livecreate, view, status, draft, link3 min▶
gh pr create --fillopens the PR and uses your branch's commits for the title and body - zero typing for a well-committed branch. Add--title/--bodyto override, or drop--fillfor an interactive prompt.gh pr view --webpops the PR open in the browser when you want the diff view or the checks tab.gh pr statusshows a dashboard: your open PRs, and ones assigned to you for review.- Draft PRs for work in progress.
gh pr create --draftopens it as a draft - CI runs, teammates can peek, but it is clearly "not ready to merge". Mark it ready withgh pr ready. - Link issues from the body. Put
Closes #12in the PR body and merging the PR auto-closes issue 12. It also cross-links them so the history explains itself.
How a working data team ships: nobody pushes to main. Every change - a new dbt model, a fixed query, a docs tweak - is a short-lived branch that lives a day or two, gets a PR, gets one review, and merges. main is always green and always deployable. That is trunk-based development, and it is why the team can release on any afternoon without a "code freeze" or a scary big-bang merge.
Self-studyMerge strategies: squash, merge commit, rebase2 min read▶
When a PR is approved, gh pr merge offers three shapes. The choice is a team convention, not a right answer - pick one and be consistent.
| Flag | What lands on main | Good when |
|---|---|---|
--squash | all branch commits collapse into one clean commit | the branch had messy WIP commits; you want a tidy main history |
--merge | every branch commit plus a merge commit with two parents | you want the full detailed history preserved |
--rebase | branch commits replayed onto main, no merge commit | you want a linear history without merge commits |
Most modern teams default to squash for a clean, one-commit-per-PR main. Session 4 covers the rebase mechanics behind that third option.
Review deep half: the reviewer side done right 5 min live
In the non-tech track you saw a PR get reviewed. Now you are the reviewer, from the terminal. Reviewing well is a craft: you approve, request changes, or comment; you can propose exact code with a suggestion the author accepts in one click; and CODEOWNERS makes sure the right person is asked automatically. Good review is where quality and mentorship both happen.
LiveApprove, request changes, suggest, and CODEOWNERS3 min▶
- Three verdicts.
gh pr review --approvegreenlights it,--request-changesblocks the merge until addressed,--commentleaves feedback without a verdict. Add-b "..."for the message. - Line suggestions. On the PR diff a reviewer can propose exact replacement code in a suggestion block; the author accepts it with one click and it becomes a commit. It turns "you should rename this" into "here, I renamed it - click to take it".
- CODEOWNERS auto-assigns reviewers. A
.github/CODEOWNERSfile maps paths to owners, so a PR touching/pipelines/automatically requests the data team. No more "who should review this?" - GitHub knows. - What good review comments look like. Specific, kind, actionable. "This loop re-reads the file each iteration - can we read once above?" beats "this is slow". Praise what is good; the PR is a conversation, not a gate.
Self-studyTrunk-based vs git-flow-lite, and branch naming2 min read▶
Two common workflows, and when each fits:
| Workflow | Shape | Fits |
|---|---|---|
| Trunk-based | short-lived branches off main, merged in a day or two; main always deployable | most modern teams, continuous delivery, small frequent changes |
| Git-flow-lite | a longer-lived develop branch plus release branches | scheduled releases, versioned products shipping to customers |
Default to trunk-based with short branches unless you have a real reason not to - long-lived branches drift from main and turn merging into archaeology. Branch naming taxonomy that reads well: feature/<short-desc>, fix/<short-desc>, docs/<short-desc>, chore/<short-desc>. Keep it lowercase, hyphenated, and about the intent.
Your first branch + PR from the CLI ★ 7 min · everyone branches
In your my-project repo: git switch -c feature/add-usage-docs. Confirm you moved with git status - it names the new branch.
Edit the README (add a short "Usage" section), then git add . and git commit -m "docs: add usage section to README".
Publish the branch: git push -u origin HEAD. (HEAD is a handy shorthand for "the branch I am on" so you do not retype the name.)
Open the PR from the terminal: gh pr create --fill. Then gh pr view --web to see your proposal live on GitHub - branch, diff, and all.
Build the history you are about to make ★ 8 min · everyone clicks
Before you merge your real PR, rehearse the exact shape here. Reproduce Build-along 1 as a graph: a commit on main, a feature branch, two commits on it, back to main, then merge. What you build in the widget is the history your PR is about to create for real.
Reproduce the branch-commit-merge shape: commit on main, make a feature branch, commit twice on it, switch back to main, merge.
Note the merge commit with two parents - that is exactly what clicking Merge on your PR (with --merge) will create. Squash would collapse the two feature commits into one instead.
Pair review via gh ★ 6 min · review both sides
Pair up. Partner A already has a PR open (from Build-along 1). Partner B: gh pr checkout <number> to pull A's branch down and read the diff locally.
Partner B leaves one comment: gh pr review <number> --comment -b "one specific, kind, actionable note". Make it real - a genuine observation about the change.
Partner B approves: gh pr review <number> --approve. Partner A watches the approval land in gh pr status.
Partner A merges: gh pr merge --squash. Both run git switch main && git pull to sync. You just did a full review cycle without opening the browser.
gh pr diff, and merge it. Reading your change as a reviewer catches surprisingly many of your own bugs - do it every time.
This week ◐ 25 min total
- Make every change a branch + PR this week - even solo. The diff review at the top of a PR catches your own bugs before they hit main.
- Add a CODEOWNERS file at
.github/CODEOWNERSmapping a path to yourself (e.g.* @your-username). Open a PR and watch yourself get auto-requested. - Try a draft PR:
gh pr create --draftfor something half-finished, thengh pr readywhen it is done. Feel the difference from a normal PR. - Read the trunk-based self-study card and decide which workflow fits your team - then write down why.
Three questions before you go 🎯 ◐ 90 seconds
1 · What does git switch -c feature-x do?
The -c flag means create. switch -c makes the new pointer and moves you onto it at once - since a branch is just a pointer (Session 1), this is instant and copies nothing.
2 · What does gh pr create make?
A PR is the GitHub proposal object: "here is my branch, please review and merge it." gh pr create opens it from the terminal; --fill borrows the title and body from your commits.
3 · What is the CODEOWNERS file for?
CODEOWNERS lives at .github/CODEOWNERS and maps paths to people or teams. When a PR changes a matching path, GitHub automatically requests that owner's review - so the right eyes see the right changes.
Official GitHub Skills coverage
This session drives the review-pull-requests Skills exercise from the CLI and covers its deep half - the reviewer side - alongside the branch and PR mechanics from Introduction to Git.
Session 3 cheat sheet · pin this
git switch -c feature/x → work → commit → git push -u origin HEAD.gh pr create --fill · gh pr view --web · gh pr status · gh pr create --draft.gh pr checkout N → read → gh pr review N --comment / --request-changes / --approve.gh pr merge --squash (tidy) · --merge (full history) · --rebase (linear)..github/CODEOWNERS maps paths to owners - auto-requests the right reviewer. Link issues with Closes #12.feature/, fix/, docs/.