Git Workflows
How teams organise branches, reviews and releases. Each workflow below comes with its rules as stated by its original source, when it fits, and an animated walkthrough — run by the Git simulator and verified against real Git.
| Workflow | Long-lived branches | How it releases | Fits best |
|---|---|---|---|
| main | Deploy main after every merged pull request | Continuously deployed apps | |
| main, develop | Release branches, tagged on main | Versioned software, several versions supported | |
| main (the trunk) | From the trunk, or a short-lived release branch | CI/CD teams integrating daily | |
| upstream’s main | Maintainers merge pull requests from forks | Open source, contributors without write access |
GitHub flow
One main branch + short-lived branches + pull requests
A lightweight, branch-based workflow. Everything in main is deployable; each change is made on its own descriptively named branch and merged into main through a reviewed pull request, then deployed.
The rules
- Anything in the main branch is deployable.
- Create a descriptively named branch off main for each change.
- Commit locally and push regularly to the branch of the same name.
- Open a pull request for feedback, or when the branch is ready to merge.
- Merge into main after review, then delete the branch.
- Deploy as soon as it is merged (in the original post: “you can and should deploy immediately”).
✓ Use it when
Web apps and services that deploy continuously from a single version.
✗ Avoid it when
You must maintain several released versions in parallel.
Sources
Opening and merging the pull request happen on GitHub; the walkthrough shows the equivalent Git operations (GitHub’s default merge button creates a merge commit).
Start the workflow and walk through it once.
1 Create a branch
2 Make changes
3 Create a pull request
4 Address review comments
5 Merge your pull request
6 Delete your branch