Introduction: Why Branch Strategy Matters

In our previous articles, we learned the basics of Git and how to create GitHub repositories. Now, let's dive deep into branch strategy, one of the most important elements in actual team projects.

Things that work fine when you're developing alone start getting complicated as the team grows. Situations like "Who's working on which feature?", "Why did this code suddenly change?", and "I need to fix a bug urgently before deployment - how do I do that?" become frequent. Branch strategy exists to solve these exact problems.

A well-designed branch strategy minimizes conflicts between team members, systematizes the deployment process, and plays a crucial role in maintaining code quality. Let's explore everything from basic branch concepts to widely used strategies in practice.

1. What is a Branch?

1.1 The Concept of Branches

Branch literally means "a limb" - like branches extending from a tree trunk. You can create multiple independent work streams from a single codebase.

Using branches allows you to develop new features or fix bugs without affecting the main code. When work is complete, you merge it back into the main code. This is how collaboration works.

A branch is a pointer to a specific commit. Creating a new branch means creating a new pointer at the current position, and subsequent commits on each branch move only that branch's pointer.

1.2 Why We Need Branches

Imagine working without branches. What would happen if all team members worked simultaneously on a single codebase?

  • Frequent code conflicts: Conflicts occur often when multiple people modify the same file.
  • Deploying incomplete code: Features still in development might accidentally get deployed.
  • Difficulty rolling back: It's hard to revert just a specific feature when problems occur.
  • No parallel work: Others have to wait until one person finishes their work.

Using branches naturally solves these problems. Everyone works in independent spaces and only merges completed work.

2. Basic Branch Commands

2.1 Creating and Viewing Branches

Let's look at the most basic branch-related commands.

# Check current branch list
git branch

# Check all branches including remote
git branch -a

# Create new branch (branching from current branch)
git branch feature/login

# Create branch and switch to it simultaneously
git checkout -b feature/login

# Or the modern way
git switch -c feature/login

2.2 Switching Branches: checkout vs switch

The switch command was introduced in Git 2.23. The existing checkout handled multiple functions including branch switching and file restoration, so these were separated for better clarity.

# Traditional method (still works)
git checkout feature/login

# New method (recommended)
git switch feature/login

# Switch back to previous branch
git switch -

Personally, I recommend the switch command. Its purpose is clear, and it prevents accidentally overwriting files.

2.3 Merging Branches

Combining a completed branch into another branch is called merging.

# Switch to main branch
git switch main

# Merge feature/login branch into main
git merge feature/login

# Delete branch after merge (optional)
git branch -d feature/login

2.4 Deleting Branches

# Delete merged branch
git branch -d feature/login

# Force delete unmerged branch (use with caution)
git branch -D feature/experimental

# Delete remote branch
git push origin --delete feature/login

3. Git Flow Strategy

3.1 What is Git Flow?

Git Flow is a branch strategy proposed by Vincent Driessen in 2010, widely used in large-scale projects. Its clear rules and structure allow all team members to work consistently.

3.2 Git Flow Branch Types

Main Branches (Always Maintained)

  • main (or master): Contains only code deployed to production. Every commit is tagged with a version number.
  • develop: Development branch for the next release. Feature branches are merged here.

Supporting Branches (Created and Deleted as Needed)

  • feature/*: For new feature development. Branches from develop and merges back to develop.
  • release/*: For release preparation. Branches from develop and merges to both main and develop.
  • hotfix/*: For urgent bug fixes. Branches from main and merges to both main and develop.

3.3 Git Flow Practical Example

# 1. Start new feature development
git switch develop
git switch -c feature/user-authentication

# 2. After feature completion, merge to develop
git switch develop
git merge --no-ff feature/user-authentication
git branch -d feature/user-authentication

# 3. Prepare for release
git switch -c release/1.0.0 develop

# 4. After final fixes in release branch, merge to main
git switch main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Version 1.0.0"

# 5. Merge to develop as well
git switch develop
git merge --no-ff release/1.0.0
git branch -d release/1.0.0

# 6. Urgent bug fix (hotfix)
git switch main
git switch -c hotfix/critical-bug

# 7. After fix, merge to both main and develop
git switch main
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "Hotfix: critical bug"
git switch develop
git merge --no-ff hotfix/critical-bug
git branch -d hotfix/critical-bug

3.4 Pros and Cons of Git Flow

Pros

  • Clear rules maintain consistency even in large teams
  • Systematic release version management
  • Clear separation between production and development code
  • Defined process for urgent fixes

Cons

  • Can be complex with many branches
  • Not suitable for frequent deployments (CI/CD)
  • Excessive overhead for small projects

4. GitHub Flow Strategy

4.1 What is GitHub Flow?

GitHub Flow is a simpler, more efficient strategy that reduces Git Flow's complexity. Proposed by GitHub, it's optimized for CI/CD environments.

4.2 GitHub Flow Rules

  1. Main branch is always deployable
  2. Create a branch from main for new work
  3. Use descriptive branch names (e.g., feature/add-login, fix/header-bug)
  4. Push frequently to remote for backup
  5. Create Pull Request when ready
  6. Merge to main after code review
  7. Deploy immediately after merge

4.3 GitHub Flow Practical Example

# 1. Create new branch from main
git switch main
git pull origin main
git switch -c feature/shopping-cart

# 2. Commit frequently while working
git add .
git commit -m "Add cart item component"
git push origin feature/shopping-cart

# 3. Additional work
git add .
git commit -m "Implement cart total calculation"
git push origin feature/shopping-cart

# 4. Create Pull Request on GitHub
# (using web interface or gh CLI)

# 5. After review approval, merge to main (usually done on GitHub web)

# 6. Clean up local
git switch main
git pull origin main
git branch -d feature/shopping-cart

4.4 Pros and Cons of GitHub Flow

Pros

  • Very simple and easy to understand
  • Suitable for continuous deployment (CD)
  • Ideal for small teams
  • Fast feedback cycles

Cons

  • Release version management is not explicit
  • Not suitable when maintaining multiple versions simultaneously

5. Trunk Based Development

5.1 What is Trunk Based Development?

Trunk Based Development (TBD) is a method where all developers work directly on a single branch (trunk or main). Used by large tech companies like Google and Facebook.

5.2 Core Principles

  • Short-lived branches: Branches are merged within a day
  • Small commit units: Even large features are split and committed frequently
  • Feature Flags: Incomplete features are hidden with flags
  • Strong test automation: Automated tests run on every commit

5.3 Feature Flag Example

// Control incomplete features with flags
const FEATURES = {
  newCheckout: false,  // Still in development
  darkMode: true       // Released
};

function renderCheckout() {
  if (FEATURES.newCheckout) {
    return <NewCheckout />;
  }
  return <OldCheckout />;
}

5.4 Pros and Cons of TBD

Pros

  • Minimizes merge conflicts
  • Optimized for continuous integration (CI)
  • Frequent code integration catches problems early

Cons

  • Requires high level of test automation
  • Feature Flag management adds complexity
  • Requires high skill and discipline from team members

6. Branch Strategy Selection Guide

6.1 Recommendations by Project Size

Project Type Recommended Strategy Reason
Small project (1-2 people) GitHub Flow Simple and fast
Startup (5-10 people) GitHub Flow Suitable for rapid iteration and deployment
Medium team (10-30 people) Git Flow or variant Systematic release management needed
Large organization Git Flow or TBD Clear rules or strong automation needed
Open source project GitHub Flow Suitable for handling external contributor PRs

6.2 Recommendations by Deployment Frequency

  • Daily or ad-hoc deployment: GitHub Flow, TBD
  • Weekly or sprint-based deployment: GitHub Flow, simplified Git Flow
  • Monthly or quarterly releases: Git Flow

7. Resolving Merge Conflicts

7.1 Why Merge Conflicts Occur

When two branches modify the same part of the same file differently, Git cannot determine which change to keep on its own. This is when a conflict occurs, and developers must resolve it manually.

7.2 Conflict Resolution Process

# Attempt merge
git merge feature/login
# CONFLICT (content): Merge conflict in src/App.js

# Check conflicting files
git status

# Opening the conflicting file shows:
# <<<<<<< HEAD
# const title = "Welcome";
# =======
# const title = "Hello World";
# >>>>>>> feature/login

Understanding conflict markers makes resolution easier:

  • <<<<<<< HEAD: Content from current branch (merge target)
  • =======: Separator
  • >>>>>>> feature/login: Content from branch being merged

7.3 Resolving and Completing the Merge

# 1. Edit file directly to write final code
# Remove all conflict markers and keep desired code

# 2. Stage resolved file
git add src/App.js

# 3. Create merge commit
git commit -m "Merge feature/login: resolve conflict in App.js"

# Or abort the merge
git merge --abort

7.4 Conflict Prevention Tips

  • Pull frequently to stay up to date
  • Keep branch lifespans short
  • Split into smaller files rather than large ones
  • Coordinate work areas with team members

8. Rebase vs Merge

8.1 Characteristics of Merge

Merge combines two branches while preserving both histories.

git switch main
git merge feature/login

Pros

  • History is accurately preserved
  • Easy to understand work context
  • Safe and easy to revert

Cons

  • History can become complex
  • Too many merge commits can accumulate

8.2 Characteristics of Rebase

Rebase "replays" commits on top of another branch. It creates history as if you had been working on that branch from the start.

# Replay feature branch on top of main's latest
git switch feature/login
git rebase main

# Fast-forward merge on main
git switch main
git merge feature/login

Pros

  • Clean, linear history
  • No unnecessary merge commits
  • Easier to track changes during code review

Cons

  • Changes history, so use with caution
  • Avoid on already pushed branches
  • Conflict resolution may be needed multiple times

8.3 When to Use What

Situation Recommendation
Cleaning up locally-only branches Rebase
Branch already pushed to remote Merge
Shared branches (main, develop) Merge
Updating feature branch Rebase (before push)
When team has rules Follow team rules
The golden rule: "Never rebase public (pushed) history." Rebasing commits that others are depending on causes major confusion.

Conclusion: Branch Strategy is Team Culture

We've explored everything from basic branch concepts to various branch strategies and conflict resolution methods. It's hard to say which strategy is the "right answer." What's important is choosing a strategy that fits your team's situation and having all team members follow the same rules.

Starting with simple GitHub Flow and adding rules as needed as the project grows is also a good approach. Branch strategy isn't something you set once and forget - it should evolve along with your team and project.

In the next article, we'll explore Pull Requests and code reviews. PRs and code reviews are essential elements for actually operating branch strategies, so be sure to read that one too.