Session 16: GitHub 101 — Fundamentals & Essentials

The session opens with Paul (yes, this cohort's Paul) writing an expense-management app on his own machine. It runs on his hardware, so he is the only beneficiary. Sharing it means shipping gigabytes to Dharmesh, Sayed and John until his storage quota dies — 'the lack of hardware will stop distributing the app.' Cloud computing solved that half: AWS (the pioneer, ~60% market share as stated), Azure and Google Cloud rent computation and storage by the unit, so the app can live on machines that scale.

But renting machines exposes three remaining gaps, and the trainer names them as insights: Paul needs to *package* his code in a standard way to move it between services; he needs a *reliable* copy somewhere safer than his breakable laptop; and he needs to *go back in time* — to know exactly which lines changed between versions. Those three needs — packaging, backup, history — are the job description Git and GitHub were hired for.

Git is an open-source version-control library, and its whole trick is diff tracking: between version 1 and version 1.1 it records only the difference. Change 'print hello world' to 'print hello world!!' and Git stores those two exclamation marks, not a second copy of the file. Each version compares to the *previous* one, not to the first — history is a chain of small deltas.

The trainer's sharper point: 'Git is not exactly the code backup. It is also the version backup.' A plain copy of your final code is nearly worthless for teamwork or debugging — without the version history you can't answer *what changed and when*, which is the question that actually matters when something breaks.

Git is the open-source version-control software: it runs locally and tracks diffs. GitHub is a platform — originally open-source-centric, acquired by Microsoft, monetized for enterprises — that stores your code *and its versions* remotely and layers on collaboration: access control, pull requests, reviews. Same relationship as your camera (Git) and a photo-sharing site (GitHub).

The confusion the session kept hitting: 'is there a local GitHub?' No — 'there is nothing concept as local GitHub.' When you clone, what you get is files plus a *connection reference*: pulls from that remote land in this folder, pushes from this folder go to that remote. GitHub Desktop and the terminal CLI are just two dashboards over the same operations.

A repository is the unit of storage and history on GitHub: one project space holding code plus all its versions. The best practice the trainer insists on for a full-stack project: split by service — frontend in one repo, backend in a second, database code in a third.

The payoff is maintainability and blast-radius control. 'If there is no change that I want to do for frontend, why would I change the entire piece of code?' A frontend tweak shouldn't drag backend history along, and separate repos also let you give collaborators access to exactly the layer they work on.

Branches are 'copies of the repository with different names': you duplicate the current state so you can edit without disturbing the original — the birthday-photos analogy: hand Karen a copy of the photos folder to edit while the originals stay safe. Real projects run more branches than you'd guess: n8n's public repo carries 1,607.

The doctrine is the hierarchy. Main holds production — the code users are touching right now — and 'you do not want to disturb it.' Below it a staging branch, below that dev, and under dev the feature branches where individuals actually work (Karen's three frontend features, Paul's two backend ones). Changes climb the tree: feature → dev (where merges happen) → staging (where load and security testing happens) → main. More people and more features just mean a bushier tree — the shape survives.

A merge conflict is exactly that: feature 1 and feature 3 both touched the same line in the same file, dev branch receives both, and asks 'which one should I prioritize?' You'll never want both. Resolution is human: keep one, discard the other, and the merge proceeds cleanly.

Who decides? 'Who is managing or accepting that merge is the final decision maker' — in an organization, an architect or senior engineer. The trainer's family analogy: two kids fighting over one pen until a parent allocates it. At scale (ten conflicted files), resolution is manual and tedious — which is where GitHub Copilot earns its keep, analyzing both versions and recommending what survives. And upstream of all of it: teams that coordinate — 'come over a call when you're ready for merge' — hit fewer conflicts in the first place.

Every saved change can become a commit: 'I commit this change for this version.' At 8 AM Akhil writes hello world; at 10 AM he adds two exclamation marks and pushes; those are two timestamps in the repo's memory. The chain of commits *is* the project's history — and any commit's code can be restored later (the session rolled back to a previous commit using its code, with Copilot assisting).

The hands-on twist: Lovable committed automatically — the escape-room app arrived on GitHub with 12 commits nobody wrote messages for. Convenient, but it surfaces a trade-off a learner spotted immediately: automation removes control. You don't choose the snapshot moments or describe them, which makes the history harder to navigate when something needs undoing.

Cloning is the first-ever pull: 'git clone <URL>' copies a remote repository to your machine — free, unlimited, no AI credits, and always remote → local. From then on the directions have names: local → remote is push, remote → local is pull. That's the whole vocabulary.

The rule that resolves every beginner confusion: 'anything happens in Rome stays in Rome — anything happens in the local system stays in the local system.' Create three branches locally and GitHub simply doesn't know until you push them. The live demo made it tactile: Akhil cloned the escape-room repo through Cursor's agent (102 files downloading), created branches named Deborah, Sayed and Dharmesh locally — remote showed nothing — then pushed, and all three appeared on github.com.

Forking duplicates an entire repository from someone else's profile to yours — remote to remote, across accounts. It only works on public repositories: you can't fork what you can't see. Once forked, the copy is yours to modify, build on, even commercialize (license permitting) — the trainer's example: admiring Paul's expense app and forking it to take it further.

Two practical uses stand out. Insurance: fork n8n's public repo (22,000 commits on master) and 'if tomorrow anything deletes this repository, you still have a copy in your profile.' And skills: public repos increasingly ship agent skills — n8n's agent-skills repo was shown — and forking is how you take a maintained skill collection and make it durably yours.

Everything Lovable pushes to GitHub arrives as a private repository, and the trainer endorses the default: 'we never know — that could be the next million-dollar app.' Notably: 'Lovable does not have the copyright of your code. Your code is yours.'

Sharing doesn't require going public. From the repo's settings you add collaborators by GitHub username or email — Sayed, Richard and Deborah were added to the escape-room repo live — and you manage what access each gets. 'You don't have to open-source your code' to work as a team; access control is the point of the platform layer.

A pull request reads oddly until you flip the perspective: *main* wants to pull code from dev, so it requests it. Opening one shows the exact diff — pluses for added lines, minuses for removed, 'to the T, whether it's an exclamation, a period, a space' — with an arrow showing merge direction.

The design insight is that raising a PR and merging it are separable powers. Junior developers can be allowed to raise PRs while 'their access stops there' — no ability to merge. Reviews become configurable gates: require, say, 2 of 3 named teammates to approve before a merge can happen. It exists 'to prevent accidents' — unstable code never reaches protected branches unreviewed. And if something bad lands anyway, any previous commit's code restores the branch (the session demoed a rollback with Copilot's help). Copilot can also pre-check a PR: 'I want to ask Copilot to do the necessary checks.'

.gitignore is a small file of patterns telling Git what never to track: '.env, .log, build folders — you should not care about them, just ignore them.' The one non-negotiable entry: .env — the file where local API keys and secrets live while you test. 'You will always have .env as part of your .gitignore. That's the best practice.'

The question that triggered this (Serendip's: what happens to API keys after a merge?) has a clean answer: they were never in the merge. Secrets are configured at the hosting-platform level — pasted into Vercel's environment settings, not into any file GitHub sees — 'because GitHub is a shared repository that you will use across your team.' Local .env for development, platform env-vars for deployment, repo carries neither.

The branch hierarchy earns its keep at deployment. In Vercel you create a separate project per branch — pick the branch in the project's settings — so merging into dev auto-deploys a dev site, merging into staging refreshes a staging site, and pushing main updates the real one. Each gets its own URL; only main gets your actual domain name — 'this is what the users will see, not these two.'

This is how real companies ship a feature: build it on dev, test it there; promote to staging for the heavier passes (can it take the load? does it hold up on security?); then, timed with the launch, merge to main and it's live. The learner question 'do commits to main auto-update the site?' gets a flat yes: once connected, 'Vercel will take care of it.'