GitHub Collaboration
- Connect a local repo to GitHub over SSH and push/pull/fetch confidently
- Work on a feature branch and explain why main stays always-shippable
- Create a merge conflict on purpose, read the markers, and resolve it correctly
- Open a pull request, review a diff line by line, and merge it
- Distinguish merge from rebase as two histories of the same work
| Spaced-rep warm-up: due flashcards (incl. Day 8 git deck) | 10 min |
| ELI5 + tech read: remotes, branches, conflicts, PRs | 20 min |
| Guided: SSH + first push, then the manufactured conflict | 40 min |
| Practice: the self-review PR | 20 min |
| Project: make the repo public-grade | 20 min |
| Quiz + flashcards | 10 min |
Builds on: Day 8 — Git fundamentals — the time machine · Day 17 — The packaged analyzer repo
Two carpenters renovating the same house can't both plane the same door at once — one of them ends up with wood shavings and no door. So real crews work differently: the site office holds the master blueprint (the GitHub remote), and each carpenter takes a copy, builds their piece in a separate room (a branch), and when the room is done, calls the site inspector for a walkthrough (a pull request) before the room is joined to the house. If two people did touch the same wall, the blueprints don't guess — they flag the wall with bright tape (conflict markers) and make a human decide which version stands, or how to combine them.
The crucial mindset shift from Day 8: git stops being your private time machine and becomes a coordination protocol. push mails your save points to the site office; fetch collects everyone else's without changing your room; pull collects AND applies them. And the house rule that makes it all work: the main blueprint must always describe a livable house — unfinished experiments live on branches, never on main.
Every job you will ever hold runs on this workflow — branch, PR, review, merge is how software teams breathe. Your GitHub profile is also your portfolio: from Day 21 onward, every project in this program ships there, and hiring managers genuinely read it (Day 180's checklist counts on that). The PR skills cut both ways: writing reviewable PRs gets your work merged; reviewing diffs carefully is how you'll catch a teammate's prompt regression on Day 141. Even solo, PRs against yourself add a deliberate review pause that catches what the writing brain missed.
Guided practice
SSH keys and the first push
20 min- Terminal: generate an SSH key if you have none:
ssh-keygen -t ed25519 -C "your_email@example.com"(accept defaults). Print the public half:cat ~/.ssh/id_ed25519.pub. - On github.com: Settings -> SSH and GPG keys -> New SSH key -> paste the public key. (Never paste the private file — the one without .pub.)
- Terminal: verify the handshake:
ssh -T git@github.com— expect a greeting with your username. - On GitHub, create an empty repo named
loganalyzer(no README — your local repo already has history). Terminal: wire and push: git remote add origin git@github.com:YOURUSER/loganalyzer.gitthengit push -u origin main. Refresh the GitHub page — your Day 14–19 commit history is now public. Read your own commit messages as a stranger would.
Manufacture a conflict, then resolve it like an adult
20 min- Terminal: create a branch and change the README's first line:
git switch -c feature/readme-tagline, edit, commit. - Sabotage yourself:
git switch main, edit the SAME first line to something different, commit. Two lines of history now disagree about one line of text. git merge feature/readme-tagline— git stops: CONFLICT. Rungit status(lists the conflicted file) and open it: find the<<<<<<<,=======,>>>>>>>markers and identify which block is whose.- Edit the file to the line that SHOULD exist (combine both ideas), delete all marker lines, then
git add README.mdandgit commit. Rungit log --oneline --graph— see the two lines of history joining in the merge commit. - Repeat the whole exercise once more but resolve by keeping the branch's version untouched — resolution is an editorial decision, not a fixed recipe.
On your own
The self-review PR
20 minShip a real improvement through the full workflow with no shortcuts: branch feature/errors-by-hour -> implement a small feature in the analyzer (e.g. group error counts by hour of day) WITH a test -> push the branch -> open a PR on GitHub with a description that states what changed and why -> then switch hats: review your own diff line by line on GitHub and leave at least two genuine line comments (one question, one improvement you then actually make and push) -> merge, then git pull on local main.
Constraints: the PR description must let a stranger understand the change without reading the code; the review comments must be ones you'd be comfortable receiving.
Hints: push the branch with git push -u origin feature/errors-by-hour; GitHub will offer the PR banner. Reviewing your own code works best after a 10-minute break.
Make the repo public-grade
Turn the loganalyzer repo into something you would link in a job application: (1) a README with a one-line pitch, install instructions (pip install -e . in a venv), usage examples for each subcommand with real output, and a "running the tests" section; (2) a LICENSE file (MIT is the usual default — read its 3 clauses before adopting them); (3) a .gitignore audit (.venv/, __pycache__/, *.log); (4) two GitHub issues written as a real to-do list (one bug or improvement, one Day 21 shipping task); (5) all of it landed via a reviewed-and-merged PR, not direct pushes to main. From today, main in this repo stays always-shippable.
Common mistakes & misconceptions
- Committing directly to main out of habit. The always-shippable rule dies quietly this way; branch even for small changes — the workflow must be muscle memory before a team demands it.
- Confusing fetch and pull. fetch is always safe (downloads, touches nothing of yours); pull rewrites your working branch. When unsure of the remote's state, fetch first and look.
- Panicking at conflict markers and deleting one side blindly. The markers are a question, not an error — read both versions; the right answer is often a combination.
- Resolving a conflict but forgetting to remove the marker lines. <<<<<<< committed into a file is embarrassingly common — and your Day 18 tests will catch it only if a test touches that file.
- Rebasing a branch others (or another machine of yours) already pulled. Rewriting shared history forces everyone downstream into recovery surgery; rebase only unpushed local work.
- Pasting the private key into GitHub, or committing it. The .pub file is the shareable half; the other file never leaves your machine — treat it like a password.
Q1. git fetch vs git pull — the real difference?
Q2. When does a merge produce conflict markers?
Q3. Your public repo has no LICENSE file. Legally, what can others do with the code?
Go deeper — curated resources
- GitHub Actions preview ↗ — Peek at a minimal workflow YAML that runs pytest on every push. You'll build this properly on Day 152 — but even a 10-line version on your repo now means no broken main, ever.
- ssh -T git@github.com greets you by username; repo pushed with full history
- One conflict manufactured, read, and resolved — twice, with different editorial outcomes
- Feature merged via a PR with your own line comments; README/LICENSE/issues in place
- Quiz ≥ 2/3
← Back: Day 8 gave you commits as private save points; today they became a shared protocol. The README documents the CLI from Day 16 and the install flow from Day 17; the PR's diff discipline reuses Day 15's readability standards.
Forward →: Day 21 ships v0.1.0 through exactly this workflow. GitHub Actions turns PRs into CI gates on Day 152, eval gates ride those PRs on Day 141, and your green-squared profile is a first-class exhibit on Day 180.