Reading this alone?
Do it with peers — bi-weekly calls, $29/mo founding.
What it does
GitHub hosts your code, tracks every version of every file, and manages your entire project. It's where your source code lives, where changes get reviewed before they go live, and where your app deploys from. It also doubles as your project management system — Issues track tasks and bugs, Projects organize them into boards, and Pull Requests are where code gets reviewed and merged.
Beyond version control, GitHub is a collaboration and automation hub. Pull requests give you structured code review — even when you're reviewing your own work, the diff view catches mistakes you'd miss in your editor. GitHub Actions handle CI/CD — run tests, lint code, and deploy automatically on every push. Issues turn your backlog into something structured and searchable. And the ecosystem of integrations is massive — Vercel deploys from your repo, Copilot suggests code in your editor, and third-party tools hook in through webhooks and the GitHub API.
Why we use it
GitHub is the industry standard and everything integrates with it. Vercel auto-deploys when you push code. Supabase can link to your repo. Claude Code works directly with git to commit and branch. Your code is backed up in the cloud, versioned so you can roll back any mistake, and accessible from anywhere. Even as a solo builder, git discipline saves you from yourself — every broken change is one git revert away from being undone.
The network effect seals it — every developer tool assumes GitHub. Your Vercel project deploys from it. Claude Code commits to it. Stripe webhooks can be tested against branches. Your CI pipeline runs on GitHub Actions. And your GitHub profile IS your developer portfolio — contribution history, pinned repos, and open source work tell a story that no resume can match. Choosing GitHub isn't just picking a host for your code — it's plugging into the infrastructure that every other tool in your stack already expects.
Setup checklist
Create a GitHub account
Go to github.com and sign up. The free tier is all you need — it includes unlimited public and private repos, GitHub Issues, Projects, and Actions. Use your professional email. Choose a username you'd put on a resume — it's your developer identity and shows up in every project URL, commit, and contribution.
Install Git locally
On macOS, the easiest way is through Homebrew: brew install git (install Homebrew first from https://brew.sh if you don't have it). Verify with git --version. Then set your identity so commits are attributed to you: git config --global user.name "Your Name" and git config --global user.email "your@email.com". Use the same email you signed up to GitHub with — this is how GitHub links commits to your profile.
Set up SSH keys for GitHub
SSH keys let you push and pull code without entering your password every time. Run ssh-keygen -t ed25519 -C "your@email.com". Press Enter to accept the default file location and set a passphrase if you want extra security. Copy your public key: cat ~/.ssh/id_ed25519.pub. Then go to GitHub → Settings → SSH and GPG keys → New SSH key, paste it in, and save. Test the connection: ssh -T git@github.com — you should see a success message.
Install GitHub CLI
Run brew install gh, then gh auth login. Choose SSH as your protocol and authenticate through your browser. The GitHub CLI lets you create repos, open pull requests, manage issues, and check deploy status — all from your terminal. It's faster than clicking through the web UI and integrates cleanly with your development workflow.
Create your first repository
From the terminal: gh repo create my-project --public --clone. This creates a repo on GitHub and clones it locally in one step. Or create it on github.com with a README, then clone: git clone git@github.com:username/repo.git. Either way, you end up with a local folder connected to a remote GitHub repo. The remote is your backup and your deployment source.
Learn the git workflow
The daily cycle is four commands. git pull — always pull before starting work to get the latest changes. git add . — stage your changes. git commit -m "what you changed" — save a snapshot with a message explaining why. git push — upload to GitHub. Check your status anytime with git status to see what's changed, what's staged, and what's not tracked. Run git log --oneline to see your commit history.
Set up branch protection
Go to your repo on GitHub → Settings → Branches → Add rule for main. Check Require a pull request before merging. This prevents you from accidentally pushing broken code directly to production. Every change goes through a pull request, which gives you a chance to review the diff, run automated checks, and catch mistakes before they reach your live app.
Use GitHub Issues for task tracking
Create an issue for every feature, bug, and task. Go to the Issues tab and click New issue. Add labels like bug, enhancement, priority: high to categorize them. Reference issues in your commit messages: “fix: resolve checkout error #12”. Close them automatically from pull requests by writing “Closes #12” in the PR description. This creates a clean trail from task to code change to deployment.
Set up a .gitignore
Every project needs a .gitignore file that tells git which files to exclude. For a Next.js project, you need at minimum: node_modules/, .next/, .env, .env.local, and .env*.local. Never commit secrets (API keys, database URLs), dependencies (node_modules), or build output (.next). Set this up before your first commit — retroactively removing files from git history is painful. Use gitignore.io to generate templates for your stack.
Learn to use Pull Requests
Pull requests (PRs) are how you merge changes safely. The flow: create a branch git checkout -b feat/my-feature, make your changes, commit them, push the branch git push -u origin feat/my-feature, then create a PR with gh pr create. The PR shows the full diff of your changes, lets you add a description of what and why, and creates a space for review. Once you're satisfied, merge it into main. This is the professional workflow used by every engineering team.
Pro tips
Explain WHY in commit messages — “fix: prevent double charge on retry” not “fix bug.” The diff shows what changed; the message explains why.
Use conventional commits — feat:, fix:, chore:, refactor:, docs: prefixes keep your history readable and enable automated changelogs.
Create a PR template — add one at .github/pull_request_template.md to standardize what every PR describes: summary, test plan, and screenshots.
Star repos you reference often — they show up in your quick access and build a public trail of what you're learning.
Starter .gitignore for Next.js + Supabase
# Dependencies node_modules/ .pnp.* # Next.js .next/ out/ # Environment .env .env.local .env.*.local # Supabase supabase/.temp/ # IDE .vscode/ .idea/ # OS .DS_Store Thumbs.db # Debug npm-debug.log* # Vercel .vercel
AI prompt to get started
I'm setting up a new GitHub repository for [project name]. Help me create: 1) A comprehensive .gitignore for a Next.js + Supabase project, 2) A PR template, 3) Issue templates for bugs and features, 4) Labels I should create for project management.
Mistakes to avoid
- ✕Committing .env files or API keys — use .gitignore and rotate any keys that were ever committed, even briefly
- ✕Giant commits with 20 files changed — commit small, commit often, one logical change per commit
- ✕Working directly on main — always use feature branches, even for small changes, so you can review before merging
- ✕Not pulling before starting work — leads to merge conflicts that are confusing and time-consuming to resolve
- ✕Ignoring .gitignore — set it up before your first commit, not after you've already pushed node_modules
- ✕Not using GitHub Issues for project management — writing todo lists in notes apps instead of Issues means your AI tools can't see or work on your backlog
Reading this and want to actually do it with others?
The community is bi-weekly live calls, async accountability, and a group of builders shipping in parallel. Founding seats are $29/mo.
