AI Courses

🎥 Video lesson — video not yet migrated (source Skool video id: 3aedc11f6a254fb69cbc4252457bf32c).

GitHub Explained — Backing Up, Branching & Managing Your Code

This video walks through what GitHub is, why we use it, and the key terminology you'll hear constantly when building — commits, pushing, pulling, branches, and merge requests.

What is GitHub? GitHub is essentially Google Drive for code. Instead of backing up documents to the cloud, you're backing up your entire codebase so it's safely stored online, accessible from any device, and shareable with teammates or clients. It looks like a folder structure — because that's exactly what it is — just with some extra controls on top.

Key Files You'll See: The README is a file that describes what your project is about and how to get started — it displays on your repository's main page. The .gitignore file tells GitHub which files to exclude from uploads — things like API keys in your .env file, large media files, and node_modules (which can be reinstalled locally with a simple command). You only want small, text-based code files going up to GitHub.

Commits (Saving): A commit is just a save point. When your code is working and you're happy with it, you make a commit with a short description of what changed — "added authentication," "resolved database errors," etc. If something breaks later, you can revert back to any previous commit.

Pushing & Pulling: Pushing means uploading your local changes to GitHub. Pulling means downloading the latest changes from GitHub into your local project. If someone else on your team has pushed new code to the main branch since you started working, you'd pull those updates into your branch so you're working on the latest version.

Branches: The main branch (also called master or production) is the live, stable version of your code. When you want to build a new feature, you create a separate branch — like a safe copy where you can experiment without affecting live users. Once the feature is tested and working, you merge it back into the main branch. After merging, you delete the feature branch to keep things organised. Claude handles all the git commands for you — checkout, merge, push, delete — you just need to understand what's happening.

Pull Requests: If the main branch has been updated since you created your feature branch, a pull request brings those new changes into your branch so you're building on the latest code. It's the opposite of pushing — you're pulling updates in rather than pushing your work out.

Public vs Private Repositories: Repositories can be private (for client work or anything confidential) or public (open source). Open source means anyone can see and fork your code — like the BMAD framework we'll use later, which has 40k+ stars on GitHub. Public repos also work well as portfolio items for job interviews or showcasing your work.

The 2026 Workflow: Claude writes the code locally → you review it → commit and push to GitHub as your backup → when ready, deploy the main branch to the web using a service like Vercel. For now, the focus is just building locally and using GitHub as your code backup. You'll see all of this in practice as we start building.