Git Workflows

A Git workflow is an agreed-upon set of rules and conventions for how branches are used, how commits are structured, and how code moves from development to production. Different teams and projects use different workflows depending on their size, release frequency, and complexity.

There is no single "right" workflow — the best one is the one that matches a team's needs.

1. Centralized Workflow

Overview

The simplest workflow. Everyone works directly on a single branch — usually main. This resembles how Subversion (SVN) works and is suitable for very small teams or solo projects.

main: A ──── B ──── C ──── D ──── E (everyone commits here)

How it Works

1. Clone the repository
2. Make changes locally
3. Pull to get the latest changes before pushing
4. Push to main

Pros and Cons

2. Feature Branch Workflow

Overview

Every new feature or bug fix gets its own dedicated branch. Work is done in isolation and then merged into main via a Pull Request. This is the most widely adopted workflow for teams of any size.

main:           A ──── B ──────────────── G ──────────── K
                        \                /               \
feature-login:           C ── D ── E ──                  \
                                                           \
fix-header:                          F ─────────────────── H

How it Works

1. Create a new branch for each feature or bug fix: git switch -c feature-name
2. Work on the branch, making commits
3. Push the branch to GitHub
4. Open a Pull Request for code review
5. After approval, merge the PR into main
6. Delete the feature branch

# Example
git switch -c feature-user-profile
# ... make changes and commit ...
git push origin feature-user-profile
# Open Pull Request on GitHub
# After review and approval, merge into main

Rules

• main should always be stable and deployable
• Never commit directly to main
• Branch names should be descriptive

3. Gitflow Workflow

Overview

Gitflow is a more structured workflow designed for projects with scheduled release cycles. It uses a strict branching model with specific branch types for different purposes.

Branch Types in Gitflow

Gitflow Diagram

main:     ●───────────────────────────────● v1.0 ─────────● v1.1
           \                             / \              /
develop:    ●────●────●────●────●────●──   hotfix────────
                  \        \
feature-A:         ●──●──●──
feature-B:                  ●──●──●──●──
                                        \
release/v1.0:                            ●──(tests)──●

Gitflow Example Commands

# Start a new feature
git switch develop
git switch -c feature/payment-gateway

# ... work on the feature ...
git switch develop
git merge --no-ff feature/payment-gateway
git branch -d feature/payment-gateway

# Prepare a release
git switch -c release/v1.2 develop
# ... final tweaks, version bump ...
git switch main
git merge --no-ff release/v1.2
git tag -a v1.2.0 -m "Release version 1.2.0"
git switch develop
git merge --no-ff release/v1.2

# Emergency hotfix
git switch -c hotfix/fix-login-crash main
# ... fix the bug ...
git switch main
git merge --no-ff hotfix/fix-login-crash
git tag -a v1.2.1
git switch develop
git merge --no-ff hotfix/fix-login-crash

4. Forking Workflow

Overview

Used in open-source projects. Each contributor forks the repository into their own GitHub account, makes changes in their fork, and submits a Pull Request to the original project. No contributor has direct write access to the main repository.

How it Works

1. Fork the main repository on GitHub
2. Clone the fork locally
3. Create a feature branch in the fork
4. Make changes and push to the fork
5. Open a Pull Request to the original repository
6. Project maintainers review and merge

5. Trunk-Based Development

Overview

Developers commit directly to main (the trunk) in very small, frequent commits — sometimes multiple times per day. Feature flags are used to hide incomplete features. This workflow is popular at companies that practice continuous deployment.

main: A ─ B ─ C ─ D ─ E ─ F ─ G (everyone integrates here, very frequently)

Key Principle

Instead of long-lived feature branches, all work integrates into main frequently (at least once a day). Incomplete features are hidden behind feature toggles/flags in the code rather than kept in separate branches.

Choosing the Right Workflow

Summary

A Git workflow defines how branches are used and how code moves to production. The Feature Branch Workflow is the most universally adopted — every feature gets its own branch, merged via Pull Requests. Gitflow adds more structure for projects with scheduled releases. Forking Workflow powers open-source contribution. Choosing the right workflow improves team communication, code quality, and deployment reliability.