Git Workflows Compared: GitHub Flow, Git Flow and Trunk-Based

Git allows almost any way of working, so each team agrees on a workflow: rules for which branches exist and how code reaches production. Interviewers often ask about these three.

GitHub Flow#

The simplest workflow, and a good default for web apps and small teams.

main  ----o-------o-------o------   (always deployable)
           \     /
            o---o   feature/cart  (pull request)

1. main is always ready to deploy.
2. Create a short-lived branch for every change.
3. Open a pull request, get it reviewed, and let the tests run.
4. Merge into main and deploy.

It suits teams that deploy often and have one live version of the product.

Trunk-based development#

Everyone integrates into one main branch (the "trunk") very often, at least daily. Branches last hours rather than weeks, or developers commit directly with strong automated tests.

Unfinished features are hidden behind feature flags: the code is merged but switched off, so it can reach production safely.

if flags.is_enabled("new_checkout", user):
    show_new_checkout()
else:
    show_old_checkout()

This avoids long-lived branches and painful merges, but it needs good automated testing. Many large companies work in this way.

Git Flow#

An older, more formal workflow with several permanent branches, designed for software with planned releases.

It suits products with scheduled versions, or several versions supported at the same time, such as installed desktop software. For web apps that deploy daily, it is usually more process than you need.

Comparison#

Hotfixes#

Something is broken in production. In GitHub Flow, create a branch from main, fix the problem, and merge through a quick pull request. In Git Flow, branch from main, then merge the fix into both main and develop.

If a project keeps release branches for old versions, the fix is often cherry-picked from main to those branches.

Rules that help every workflow#

• Keep branches short-lived.
• Protect main, and require reviews and passing checks.
• Merge small changes often.
• Use the same merge style across the team.

Practice#

Key takeaway#

Next: CI with GitHub Actions.