The Pull-Request Workflow

How Teams Actually Work

Everything up to now has been about the mechanics of Git itself. This section is about the process that virtually every professional software team builds on top of those mechanics. Professional teams almost never commit straight to main - instead they use this standard flow:

1. Branch off main for your change: git switch -c feature-x
2. Commit your work in small, logical steps, with clear messages
3. Push the branch to the remote: git push -u origin feature-x
4. Open a Pull Request (PR) on GitHub (called a Merge Request on GitLab) - this is simply a formal request: "please merge my branch into main", paired with a description of what and why
5. Teammates review the diff and leave comments, automated CI (continuous integration) runs the test suite against it
6. Once approved and green, someone merges the PR into main; the feature branch is then deleted

Goal: Understand why main is treated carefully: it's usually the branch that actually ships to production, or that everyone else builds their own new branches from. A PR is the quality gate - human review plus automated tests - standing between "someone's change" and "live, trusted history".

Tip: Keep PRs small and focused on one thing. A 40-line PR gets read carefully and merged within minutes; a 2,000-line PR sits unreviewed for days, gets skimmed instead of read, and hides bugs in the noise. Small, frequent branches beat big, rare ones almost every time.

Note: A fork is your own personal, server-side copy of someone else's repository - it's the standard way to contribute to open-source projects you don't have write access to. You fork the project, clone your fork, branch, commit, push to your fork, then open a PR from your fork back to the original project. (The dedicated "Forks & Keeping in Sync" section later in this track covers the exact commands.)