Git is powerful for solo work, but its true magic shines in teams. Multiple developers, parallel branches, constant merges—Git becomes the conductor of collaboration. But raw Git commands aren’t enough; you need structured workflows. Three dominate the landscape: GitHub Flow, GitLab Flow, and Trunk-Based Development. Each offers a philosophy for how teams dance together.


Why Workflows Matter

Without agreed rules, chaos reigns: long-lived branches, endless conflicts, broken main branches. Workflows provide guardrails. They define how features, fixes, and releases flow from idea to production. They shape collaboration.

Visualization:

flowchart TD
  Idea[Idea] --> Branch[Feature Branch]
  Branch --> Review[Pull Request / Merge Request]
  Review --> Main[Main Branch]
  Main --> Deploy[Deployment]

GitHub Flow

GitHub Flow is simple, fast, and suited to continuous delivery.

Steps:

  1. Create a branch from main.
  2. Commit changes.
  3. Open a pull request.
  4. Discuss, review, and update.
  5. Merge into main.
  6. Deploy immediately.

Visualization:

gitGraph
  commit id: "main A"
  branch featureX
  checkout featureX
  commit id: "feature work"
  checkout main
  merge featureX
  commit id: "deploy"

Pros:

  • Simple, easy to learn.
  • Encourages frequent deployment.
  • Perfect for web apps with CI/CD.

Cons:

  • Not ideal for complex release management.

GitLab Flow

GitLab Flow adds environment awareness: staging, production, and release branches.

Steps:

  • Feature branches → merged into main.
  • main → deployed to staging.
  • Release branches → deployed to production.

Visualization:

gitGraph
  commit id: "main dev"
  branch featureY
  checkout featureY
  commit id: "feature done"
  checkout main
  merge featureY
  branch release1
  checkout release1
  commit id: "hotfix"
  checkout main

Pros:

  • Handles environments (staging, production).
  • Balances speed and stability.

Cons:

  • More complex than GitHub Flow.
  • Requires discipline to maintain environment branches.

Trunk-Based Development

Trunk-based development is radical simplicity: everyone commits directly to main (the “trunk”). Feature flags hide incomplete work. No long-lived branches.

Steps:

  • Developers branch briefly or commit directly.
  • Integrate multiple times per day.
  • Use feature toggles to manage unfinished code.

Visualization:

gitGraph
  commit id: "main A"
  commit id: "dev commit"
  commit id: "another dev commit"
  commit id: "toggle new feature"

Pros:

  • Fastest feedback.
  • Minimal merge conflicts.
  • Works great with CI/CD.

Cons:

  • Risky without strong tests and feature flags.
  • Can feel chaotic for large teams without automation.

Choosing a Workflow

  • GitHub Flow: best for small teams, startups, continuous delivery.
  • GitLab Flow: best for teams with staging/production environments.
  • Trunk-Based: best for high-performing teams with strong CI/CD discipline.

Solo Workflow Example

Even solo developers can adopt workflows. GitHub Flow suits solo projects: branch, commit, PR (even if self-reviewed), merge, deploy.


Team Workflow Example

On a large team: GitLab Flow ensures production safety. Devs work on features, merge into main, test in staging, then promote to release branches for production. This keeps environments consistent.

Visualization of promotion flow:

flowchart LR
  Dev[Feature Branch] --> Main[Main/Staging]
  Main --> Release[Release Branch: Production]
  Release --> Users[Deployed to users]

Think Different Mindset

Workflows are not bureaucracy—they’re choreography. They define how developers dance together without stepping on toes. Git teaches that collaboration is both technical and cultural. Pick the workflow that matches your rhythm, then dance with discipline.


GitHub Flow, GitLab Flow, and Trunk-Based Development are not competing religions—they’re tools for different contexts. Simple teams thrive with GitHub Flow, disciplined teams shine with Trunk-Based, and cautious teams succeed with GitLab Flow. In the next chapter, we’ll see how Git and CI/CD meet, closing the loop from commit to deployment.