Repos, Branches, and the Pull Request Workflow

GitHub is where most of the world's code lives and where teams actually collaborate on it. If cc-pro-version-control taught you what git is under the hood, this lesson is about how real teams use GitHub day to day.

The core objects, in plain terms:

• A repository ("repo") is a project's entire history, hosted on GitHub. Anyone with access can clone it — download a full working copy, including every past version.
• A branch is an isolated line of work. You create one to make a change without touching the shared, working version everyone else relies on. When your change is ready, it merges back in.
• A pull request (PR) is a proposal: "here's my branch, here's what changed, please review it before it becomes part of the real project." This is the collaboration layer — comments, requested changes, approvals, all attached to a specific set of code changes before they land.

The workflow that scales from a team of 2 to a team of 2,000:

1. Create a branch for your change.
2. Make the change, commit it, push the branch to GitHub.
3. Open a pull request describing what and why.
4. A teammate reviews it — reads the diff, tests it, comments or approves.
5. Once approved, it merges into the main branch.

Why this matters even if you don't write code: every serious engineering team you work with — internal or vendor — uses some version of this flow. Understanding it means you can ask a meaningful question like "is this in a pull request yet?" instead of just trusting that work happened.

▶️ Try this

Find a public, well-known open-source project on GitHub (React, or any tool you use) and look at its "Pull Requests" tab. Read one recent merged PR's description and comments. That's the exact process your own team's code changes go through.