Branches + pull requests: the flow that kills final_v3_FINAL.docx

Here is the friendly secret: the web editor offers the branch to you. Open a file, click the pencil ✏️, make your edit, press Commit changes - and if you should not be writing to main directly, GitHub shows a radio button: "Create a new branch for this commit and start a pull request." Pick it, and the safe copy plus the proposal appear together. No ceremony.

• Name the branch after the change: clarify-expense-policy, fix-onboarding-typo, add-travel-section. Future readers (including future you) thank present you.
• One branch, one topic. A branch that changes ten unrelated things is as unreviewable as an email titled "misc updates".
• Branches are cheap and disposable. Make one for a two-word edit. After the merge it gets deleted and nothing of value is lost - the history moved into main.

• Seeing them: the branch dropdown at the top-left of the Code tab (it usually says "main") lists every branch in the repo. Click one to browse the repo as that draft sees it - a whole parallel world, one click away.
• Branches end one of two ways: merged (the purple badge - the draft became truth) or deleted unmerged (the proposal was declined, main untouched). Both endings are safe; neither loses history that reached main.
• Stale branches - drafts someone opened and forgot - are the repo's junk drawer. Deleting a merged branch is always safe; ask before deleting an unmerged one, exactly as you would before binning a colleague's marked-up printout.

• Red lines = removed, green lines = added. A changed sentence shows as one red line (the old) plus one green line (the new). Reviewers see exactly what would change - never a wall of maybe-different text.
• The Conversation tab collects every comment, decision and "why we did this" - attached to the change forever. Six months later, the reasoning is one click away instead of buried in someone's inbox.
• Draft PRs say "not ready yet - look, but do not review formally". Perfect for work in progress you want visible early.
• Closing without merging = proposal declined. Main never changed, the branch can be deleted, and the discussion stays on record. Saying no is safe, cheap and polite here.

• Comment: attach a note to one specific line. No more "in the third paragraph on page 2, I think...". The line itself carries the discussion.
• Suggest: the ± icon in the comment box lets you type the exact replacement text. The author sees your version rendered as its own mini diff and clicks Commit suggestion - your fix lands, attributed to both of you, no retyping. This one button converts vague feedback into finished work.
• Request changes: the formal "not yet" - the PR shows a visible block until concerns are resolved.
• Approve: the formal thumbs-up. Convention: the author merges after approval - reviewers advise, the proposer ships.

Then the merge: one green button, the badge flips to purple Merged, the branch gets deleted, main is updated, and every commit and comment is preserved in the history. The draft became the published truth, with a paper trail.

Merge conflicts, one paragraph: if two people edit the same line of the same file on different branches, GitHub cannot guess which version wins - so it shows both, marked clearly, and asks a human to pick. The web UI has a built-in editor that handles simple cases in a minute (choose one version, or blend them, then confirm). Genuinely gnarly conflicts are tech-track territory; your defense in a docs repo is simply small PRs merged promptly, which makes collisions rare.

Branch protection: Settings → Branches → add a rule on main requiring 1 approving review before merge. That single setting turns review from a favor into a rule - nobody, including the repo owner on a rushed Friday, can push straight to the published truth. It is this week's homework for a reason.