3.2 GitHub Flow

Why GitHub Flow is a Domain 1 skill

The GH-900 outline asks you to explain the GitHub Flow for collaboration. That is a named workflow, not a vague "use pull requests" slogan. GitHub publishes it as a lightweight, branch-based workflow that GitHub itself uses for site policy, documentation, and the public roadmap—evidence that it is not only for application code. Non-developers on this exam are expected to follow the same loop when they edit a Markdown guide or a policy file.

GitHub Flow assumes a single long-lived default branch (commonly main since GitHub changed the default name in 2020; the name is configurable) that should remain deployable. All new work happens on a short-lived topic branch. Collaboration happens through a pull request. When the work is accepted, you merge and delete the branch. That is the entire happy path.

GitHub's docs are explicit that you can complete all steps through the GitHub web interface, the command line and GitHub CLI, or GitHub Desktop. A question that claims GitHub Flow "requires the Git CLI" is wrong. A question that claims it "can only be done in the browser" is also wrong. The workflow is client-agnostic; the sequence is not.

The six steps

1. Create a branch

Create a branch in the repository with a short, descriptive name so collaborators can see ongoing work at a glance—increase-test-timeout or add-code-of-conduct, not fix or my-work. The branch is a safe workspace: changes do not affect the default branch until you merge. Creating the branch is also how you invite review later; there is no review of work that exists only in an uncommitted editor buffer.

GitHub Flow wants one branch per set of unrelated changes. If you mix a documentation fix with an API redesign on the same branch, reviewers cannot approve one without the other, and a delay in the redesign parks the docs fix. If one idea is delayed, the other ideas should still be able to ship.

2. Make changes and commit them

On that branch, add, edit, rename, move, or delete files. Commit and push so the work is backed up on GitHub and visible to collaborators from any device. Write descriptive commit messages (fix typo, increase rate limit) so future readers can see what changed without opening the diff first.

GitHub's guidance is that each commit should contain an isolated, complete change. Rename a variable in one commit and add tests in another. If you later keep the tests but drop the rename, you revert one commit instead of surgically editing a mixed commit. If you squash unrelated edits into a single blob, GitHub Flow still works, but you throw away the recovery property the workflow is designed around. The branch remains a safe place to make mistakes: revert, amend locally before sharing, or push follow-up commits. Nothing lands on the default branch until merge.

Keep committing until you are ready for feedback. You do not have to finish the entire feature before anyone else sees it—that is what draft pull requests are for.

3. Open a pull request

A pull request (PR) asks collaborators to review the branch. Some repositories require an approving review before merge; even when they do not, review is the collaboration mechanism GitHub Flow is built on.

If you want early feedback before the work is complete, mark the pull request as a draft. Draft is an official GitHub Flow move, not a workaround. It signals "please comment, but do not treat this as ready to merge."

When you open the pull request, write a summary of the changes and the problem they solve. Use images, links, and tables if they help. If the pull request addresses an issue, link the issue. Linking with a supported keyword (Closes #10, Fixes octo-org/octo-repo#100) will close the issue automatically when the pull request merges into the default branch. You can also comment on specific lines to point reviewers at a risky hunk.

Repositories can automatically request review from teams or users; you can also @mention people or request reviewers by hand. If status checks (often GitHub Actions) run on pull requests, failed checks show on the PR so you catch errors before merge.

4. Address review comments

Reviewers leave questions, comments, and suggestions on the whole pull request or on specific lines and files. They can attach images or code suggestions. You respond by committing and pushing to the same branch; the pull request updates automatically. GitHub Flow does not ask you to open a new pull request for every review round. It asks you to keep the conversation on one PR until the branch is right.

5. Merge the pull request

When the pull request is approved—and when it satisfies any branch protection rules such as a required number of reviews or a required team approval—you merge. Merge incorporates the branch into the default branch. GitHub keeps the history of comments and commits on the pull request so future contributors can see why the change landed.

GitHub blocks the merge when conflicts exist; you resolve them before merging. Protection rules can also block a green-looking PR that lacks a required review or a passing check. Those blocks are features of the repository, not extra GitHub Flow steps, but they sit on the merge gate you must explain.

6. Delete the branch

After merge, delete the branch. Deletion signals that the work is complete and stops people from accidentally building on a stale branch. You do not lose the record: the pull request and commit history remain. You can restore the deleted branch or revert the pull request if the change needs to come out.

That delete step is easy to skip in real life and easy to forget on the exam. GitHub Flow is not finished at merge.

GitHub Flow vs Git Flow

Git Flow (the model popularized with develop, release, and hotfix branches) keeps multiple long-lived branches. Feature work branches from develop. Releases cut from develop into a release branch, then into production (master/main). Emergency production fixes use dedicated hotfix branches. That model fits scheduled release trains. It is not what GH-900 names in Domain 1.

GitHub Flow keeps one long-lived default branch that should stay shippable. Topic branches are short-lived. Integration happens in the pull request, not on a standing develop line. Hotfixes are just another topic branch off the default branch, reviewed and merged the same way. If an exam option describes creating develop plus release/1.2 plus hotfix/critical, that is Git Flow. If it describes main (or your default) plus fix-login-button plus a pull request, that is GitHub Flow.

GitHub Flow is useful for everyone, not just developers. Policy files, docs, and roadmaps follow the same branch-and-PR loop. That is why the skill sits in "Working with GitHub" rather than in an advanced Git chapter.

Practical rules GitHub calls out

• Name branches so a stranger understands them in the branch list.
• Prefer isolated commits so you can revert one idea without dragging another idea with it.
• Use a draft pull request when you want advice before the work is finished. Draft is part of the official flow.
• Link issues from the PR body. Keywords close issues only if the pull request targets the default branch. A PR into develop or any other non-default branch will not auto-close issues via those keywords.
• Watch status checks on the pull request. Failed checks are a reason not to merge, even if a human already approved.
• Treat branch protection as a merge gate sitting on step 5, not as a replacement for the flow.
• After merge, delete the branch. Restore or revert if you must; do not hoard merged feature branches.

Clients: web, CLI, Desktop

GitHub Flow is the same six steps whether you click through github.com, run git/gh in a terminal, or use GitHub Desktop's GUI. Choose the client for the environment (browser kiosk, local IDE, no-CLI preference), not a different workflow. Desktop is the visual path; CLI is the scriptable path; the web UI is the zero-install path. Domain 1's next bullets cover Desktop and Mobile as when to use questions; this bullet is what sequence to follow.

Exam traps

• Working directly on main is not GitHub Flow. The default branch stays stable because topic branches absorb risk.
• Opening a pull request is not optional coloring around a merge you already did locally to default. The PR is the collaboration step.
• "Create a release branch from develop" is Git Flow language. Do not pick it for GH-900 unless the question explicitly contrasts the two and asks for Git Flow.
• Draft PRs are for incomplete work; they are not a sign you skipped GitHub Flow.
• Deleting the branch is a cleanup signal, not data destruction. The PR remains the archive.
• Auto-close keywords in a PR that targets a non-default branch are ignored. That detail is in GitHub's linking docs and is a favorite trick when issues and PRs show up together.

If you can narrate "branch, commit, PR, review, merge, delete" and contrast it with Git Flow in one sentence, you have the Domain 1 collaboration model the exam wants.