GitHub Flow: A Simple, Branch-Based Workflow
GitHub Flow is a simple workflow where main is always stable and new work happens on a feature branch. It's used for continuous delivery, from code to documentation.
Why it exists
To provide a simple, clear process for collaboration that ensures the main line of development (the main branch) remains stable and working at all times. It was designed for teams that practice continuous delivery and need a lightweight way to manage changes without the complexity of multiple long-lived branches.
The mental model
Think of the main branch as the single source of truth—it's always pristine and deployable. Any new feature, bug fix, or even documentation update is a temporary detour taken on its own separate branch. This detour is only merged back onto the main road after it has been reviewed and approved by your collaborators.
How it works
The flow follows a few simple steps. First, create a descriptively named branch from main (e.g., increase-test-timeout). Second, make your changes and add commits to this branch. Your branch is a safe space; mistakes won't affect main. Third, push your branch to the remote repository. Fourth, open a Pull Request to propose your changes, which allows teammates to review your work and provide feedback. Fifth, once the Pull Request is approved and any automated checks pass, merge it into the main branch. The feature branch can then be deleted.
When to use it
GitHub Flow is ideal for projects that practice continuous delivery or continuous deployment. Because main is always stable, any merge can potentially be deployed to production immediately. This makes it perfect for web applications, services, and documentation sites where you want to ship improvements frequently and safely.
When not to use it
This workflow is less suitable for projects that have scheduled release cycles or need to support multiple versions in production simultaneously (e.g., a desktop or mobile app with versions 1.1, 1.2, 2.0). In those cases, a more complex workflow like Git Flow, with its dedicated develop and release branches, might be a better fit.
One canonical example
A developer needs to fix a typo on a website. They create a branch named fix-homepage-typo. They edit the file, commit the change with the message "Fix typo in hero section," and push the branch. They then open a pull request. A teammate reviews the change, approves it, and merges the branch into main. The merge automatically triggers a deployment, and the fix is live within minutes.
Interview question
Which principle is fundamental to the GitHub Flow workflow, enabling its use for continuous delivery?
- a.The 'main' branch is consistently maintained in a deployable and stable condition.Correct
- b.Releases are managed through separate, long-lived 'release' branches.
- c.Developers must obtain approval from a release manager before creating any new branches.
- d.All new features are developed on a dedicated 'develop' branch before being merged into 'main'.
Why? this is the answer
The core tenet of GitHub Flow is that the 'main' branch is always stable and deployable, allowing for continuous delivery. Option D describes a characteristic of other workflows like Git Flow, not GitHub Flow, which uses short-lived feature branches directly from 'main'.
Just read this? Test yourself on what you have been reading.
Read the original → docs.github.com
- #git
- #workflow
- #github
- #ci/cd
- #collaboration
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on git — each one lists the topics its interview covers.
See open roles