In Git, two popular models for managing a project's workflow are Trunk-based development (Trunk Flow) and the Forking Workflow (Forking Flow). Below is a detailed introduction and comparison of the two.
Trunk Flow keeps everyone on one main branch, usually main or master. Feature branches stay short, ideally under a few days, and merge back early by squash or rebase. Forking Flow gives each developer a private copy. Finished work returns as a pull request, and only a maintainer merges it. Trunk Flow favors speed and CI. Forking Flow favors access control, especially for open source.
Trunk Flow (Trunk-based Development)
Trunk Flow is a development model in which all developers work directly on a single main branch (usually main or master). Side branches (feature branches) are typically created temporarily and merged back as early as possible.
Process
- Each developer creates a feature branch from
main. - Keep the work short, ideally under a few days.
- Merge back into
mainearly (usually by squash or rebase). - CI/CD can be used to verify before merging.
Advantages
- Clean, linear Git history.
- Easy to integrate continuous CI/CD.
- Encourages frequent, quick code review.
- Suitable for small to medium teams.
Disadvantages
- Requires a high degree of synchronization within the team.
- Merge conflicts are likely when many people work at once.
Forking Flow (GitHub Flow / Forking Workflow)
Each developer works on their own copy (fork) of the main repo. When finished, they submit a Pull Request (PR) to merge into the original (upstream) repo.
Process
- The developer forks the main repo into their own copy.
- Create a branch from the fork → work → commit.
- Push to the fork → open a Pull Request to the original repo.
- The main repo's maintainer reviews and merges the PR.
Advantages
- High security (very well suited to open source).
- Lower risk for the main repo because nobody pushes to it directly.
- Makes it easy to collaborate with outsiders (contributors).
Disadvantages
- Continuous CI/CD is hard to set up without explicit configuration.
- More complex workflow: you need to sync with upstream.
- Pull requests can go stale if the fork is not actively updated.
Trunk Flow vs Forking Flow
| Criterion | Trunk Flow | Forking Flow |
|---|---|---|
| Main goal | Development speed, fast CI/CD | Security, control over the community |
| Used for | Internal projects, small to medium teams | Open-source projects, external contributors |
| Development style | Short branches, fast merges | Work on a fork, send PRs to the original repo |
| Complexity | Simple | More complex, requires syncing the fork |
| Branch structure | Few branches, usually main + feature |
Each person uses their own fork |
| Risk to the main repo | Higher (people push directly) | Lower (only maintainers can merge) |
| Ease of CI/CD | ✅ Very easy to integrate | ❌ Needs extra setup |
Conclusion
| You should use | If... |
|---|---|
| Trunk Flow | You work in an internal team and want fast CI/CD rollout and a clear Git history. |
| Forking Flow | You develop an open-source project, collaborate with strangers, and need to control access permissions. |
Trunk Flow aims at development speed and fast CI, and it fits internal teams of small to medium size. The cost is tighter synchronization, because many people on one branch raise the chance of conflicts, and direct pushes put more risk on the main repo. Forking Flow aims at security and control of a community. Contributors work on a fork, so they do not push to the main repo directly. CI is harder until someone configures it, the fork must be synced, and a pull request can go stale. Use Forking Flow when the project is open source and strangers need reviewed access.
See also: Git And GitHub · Developer Tools And Environments