Comparing Git Workflows

Choosing the right branching strategy is one of the most important decisions a team makes. There is no single "best" workflow — the right choice depends on your team size, release process, and project type.

Git Flow

The original structured workflow, designed for projects with scheduled releases.

Branches:

• main — always reflects production
• develop — integration branch for features
• feature/* — individual features branch from develop
• release/* — prepare a release (freeze features, fix bugs)
• hotfix/* — emergency fixes branch from main

main:     ──●──────────────●──────●──
             \            /      /
develop:      ──●──●──●──●──●──●──
                 \    /
feature:          ──●──

Best for: Large teams, versioned software (desktop apps, libraries), scheduled releases.

Downsides: Complex, many long-lived branches, slow feedback loops.

GitHub Flow

A simplified workflow built around pull requests and continuous deployment.

Branches:

• main — always deployable
• feature-name — short-lived branches for each change

main:     ──●──●──●──●──●──
              \   /
feature:       ──●──

Process:

1. Create a branch from main
2. Make commits
3. Open a pull request
4. Review and discuss
5. Merge to main
6. Deploy

Best for: Web apps, SaaS products, small-to-medium teams, continuous deployment.

Downsides: No concept of releases or environments. Simple — but maybe too simple for complex projects.

GitLab Flow

Extends GitHub Flow with environment branches.

Branches:

• main — development integration
• production — reflects what's deployed
• staging (optional) — pre-production testing
• Feature branches — same as GitHub Flow

main:        ──●──●──●──●──
                        \
staging:                 ──●──
                            \
production:                  ──●──

Best for: Teams that need environment tracking, companies with staging/production pipelines.

Downsides: Extra branches to maintain. Merging flows downstream only.

Trunk-Based Development

The simplest workflow. Everyone commits to a single branch (the "trunk"), often using feature flags.

Branches:

• main (the trunk) — all work happens here
• Short-lived feature branches (optional, merged within hours)

main:  ──●──●──●──●──●──●──●──

Process:

1. Pull latest main
2. Make a small change
3. Run tests
4. Push to main (or merge a tiny PR)
5. Deploy with feature flags

Best for: Experienced teams, high-trust environments, continuous integration, Google/Meta-scale engineering.

Downsides: Requires strong CI/CD, feature flags, and disciplined developers. Risky without good test coverage.

Decision Matrix

How to Choose

Ask these questions:

1. How often do you release? Monthly → Git Flow. Daily → GitHub/Trunk-Based.
2. How big is your team? 2-5 people → GitHub Flow. 50+ → Git Flow or Trunk-Based.
3. Do you need multiple environments? Yes → GitLab Flow.
4. How strong is your CI/CD? Weak → Git Flow. Strong → Trunk-Based.
5. Do you version your software? Yes (v1, v2) → Git Flow. No → GitHub Flow.

No Workflow is Permanent

Teams evolve. Many start with GitHub Flow, then adopt GitLab Flow as they add environments, or move toward trunk-based as their CI matures. The best workflow is the one your team actually follows consistently.

Congratulations!

You've completed the Advanced Git module and the entire Git Tour. You now have a solid understanding of:

• Git basics — init, add, commit, status, log
• Branching — branch, checkout, merge, conflict resolution
• History — log, diff, stash, reset, revert
• Remotes — clone, remote, push, pull
• Advanced tools — tag, reflog, bisect, hooks, aliases, workflows

You're equipped to work confidently with Git in any team or project. Keep practicing, explore the commands you found most interesting, and remember — the reflog is always there to save you.

Happy committing!