Learn Git - Understanding Git Collaboration Workflows

#Introduction

The last four episodes equipped you with the full set of commands: branch, merge, push, pull, and even remote branch deletion. But commands are only tools; in the real world, teams that equally understand Git can work in very different ways. This difference is what we call a collaboration workflow.

A workflow is the rulebook: when to create branches, which branches must always exist, how code reaches production. Your workflow choice affects release speed, risk level, and your team's review culture. In this episode we map out the four best-known patterns — from the simplest to the one used by the biggest tech companies.

#What Is a Collaboration Workflow?

Simply put, a workflow answers three questions:

Which branch does work start from?
How are new features developed and tested?
How does the final code reach production?

There is no single absolutely correct answer — every pattern has trade-offs. What matters is choosing one that fits your team size, release cadence, and process maturity. The good news: you already master every command needed to execute these patterns: git switch -c to open a branch, git merge to integrate, and git push to send code.

#Centralized Workflow

The simplest pattern, similar to how SVN works: everyone commits directly to main. No feature branches, no Pull Requests. Small, fast changes.

Centralized Workflow flow

main
  developer A: commit -> push
  developer B: pull -> commit -> push
  developer C: pull -> commit -> push

Its strength is simplicity and minimal configuration. Its weakness is clear: there is no protection against mistakes, and every conflict happens right on the production branch. It suits personal projects, prototypes, or extremely small teams.

#Feature Branch Workflow

The most popular pattern today. Every new feature is developed on a separate branch, then merged back after approval through a Pull Request. The main branch is always in a release-ready state.

Feature Branch Workflow flow

git switch -c feature/checkout
# kerjakan fitur, beberapa commit
git push -u origin feature/checkout
# buka Pull Request ke main

Its strengths: risk isolation, tidy history, and review happens before code touches main. This is the safest combination for small to medium teams, and the foundation of the default GitHub workflow.

#Gitflow Workflow

Developed by Vincent Driessen (2010), Gitflow brings a more formal set of branches: main for official releases, develop as the daily integration point, plus feature/*, release/*, and hotfix/*.

feature/* branches off develop and returns to develop.
release/* prepares the next release from develop, then merges into main and develop.
hotfix/* branches off main for urgent production fixes, merging back into both.

Gitflow branch structure

main
  \ develop
      \ feature/login
      \ feature/payment
      \ release/1.2.0
      \ hotfix/critical-bug

Gitflow excels for projects with scheduled releases and strict semver. But its formality weighs down small teams: two permanent main branches plus a number of supporting branches make history and conflicts more complex. Many modern teams actually leave it behind in favor of simplicity.

#Trunk-Based Development

The modern approach favored by the CI/CD ecosystem. Everyone works on short-lived branches (a few hours to a few days), then integrates them into main (the trunk) as often as possible — ideally several times a day. Large features do not hide in long branches; changes are controlled through feature flags.

Trunk-Based Development flow

main
  branch kecil A  -> merge ke main (hari ini)
  branch kecil B  -> merge ke main (hari ini)
  branch kecil C  -> merge ke main (besok)

Its strengths: conflicts are rare because branches are short, continuous integration surfaces bugs quickly, and main always stays close to production. This is the pattern that lets teams deploy dozens of times a day like GitHub, Netflix, and Google.

Important

Trunk-Based Development can only really be used when the CI pipeline is fast and the review culture is lightweight. Without both, "small but frequent merges" will become a review queue bottleneck.

#Comparing the Four Workflows

Workflow	Key Branches	Feature Branch Lifetime	Strengths	Weaknesses
Centralized	`main` only	None	Simplest	No safety net, conflict-prone
Feature Branch	`main` + feature branches	Days to weeks	Isolation and PR review	Long branches can go stale
Gitflow	`main`, `develop`, `feature/`, `release/`, `hotfix/*`	Weeks to months	Scheduled releases, strict semver	Complex for small teams
Trunk-Based	`main` only	Hours to days	Fast integration, CI/CD friendly	Needs discipline and feature flags

#Choosing the Right Workflow

Practical guidance for choosing:

Teams of 1-3 people with no strict releases → Centralized as a starting point.
Teams of 3-20 people with one release per week or month → Feature Branch with PRs.
Projects with scheduled releases and mandatory semver → Gitflow.
Product teams with strong CI/CD and daily deploys → Trunk-Based Development.

An important rule: a workflow is a tool, not a dogma. Many teams use a mix — for example Feature Branch for large features and Trunk-Based for small hotfixes. The only truly bad thing is inconsistency.

#Closing

Key points of this episode:

Centralized: everyone pushes to main, suited to very small projects.
Feature Branch: each feature lives on its own branch, merged through a PR.
Gitflow: main, develop, feature/*, release/*, hotfix/* for scheduled releases.
Trunk-Based: short branches, frequent merges to main, the mainstay of modern CI/CD.
There is no perfect workflow; choose based on team size and release cadence.

You now have a foundation of commands and collaboration patterns. In episode 11 we put it into practice through Pull Requests and Code Review on GitHub — how to open PRs from the UI or the gh CLI, write informative descriptions, and choose a merge commit strategy. See you there!