What's changed: Expanded content (added diagrams)
2.4GitHub Flow (the basic delivery pattern)
Learn GitHub Flow, a lightweight branching pattern for individuals and teams: create branch → commit → Pull Request → review → merge → deploy, and what each step means.
How do you combine the tools you have learned (branches, commits, Pull Requests) in real development? The standard, lightweight pattern is GitHub Flow. It has no heavy rules—just a flow for delivering changes small and safe.
2.4.1The six steps of GitHub Flow
- Create a branch: branch a short-lived feature branch off
main. - Commit: record changes in meaningful units.
- Pull Request: propose the change and start discussion/review.
- Review / discuss: incorporate feedback and pass automated CI checks.
- Merge: once approved, integrate into
main. - Deploy: ship the contents of
main.
2.4.2Why this pattern works
- Keeps
mainalways deployable. - Changes stay small, making them easy to review and safe.
- PRs preserve discussion and history so you can trace decisions later.
- Combined with CI, you get automated checks before merge.
Keep branches small and short-lived, and open PRs frequently. Smaller PRs are faster to review and merge, and less prone to conflicts.
As a rule, do not push directly to main (you can enforce this with branch protection). Long-lived branches drift from main and cause conflicts.
Common points: the GitHub Flow order (branch → commit → PR → review → merge → deploy), "keep main always deployable," and "integrate via short-lived branches and PRs."
2.4.3Section summary
- GitHub Flow = create branch → commit → PR → review → merge → deploy
- Keep
mainalways deployable; do work on short-lived feature branches - Do not push directly to
main; integrate through PRs and review
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What is the first step of GitHub Flow?
Q2. Which correctly describes how main is treated in GitHub Flow?
Q3. What should changes pass through before being merged into main?