Branching Strategies (Trunk, GitFlow, GitHub Flow)

This lesson on Branching Strategies (Trunk, GitFlow, GitHub Flow) is hands-on and example-driven. You will be able to organize collaborative development using industry-standard branching workflows. You will master the practical Git commands necessary to implement the Feature Branch workflow and select the appropriate strategy (GitFlow or GitHub Flow) based on your project's release cadence and stability requirements.

What You'll Be Able To Do

• Execute the full feature branch lifecycle using core Git commands (switch, commit, merge, branch -D).
• Define the purpose of the five specialized branch types used in the GitFlow model.
• Determine the appropriate branching strategy based on project size and release frequency.
• Implement the core GitHub Flow principle that the main branch must always be deployable.
• Integrate isolated work back into a stable branch using the correct merging sequence.

Detailed Concept Walkthrough

1. Feature Branch Workflow Lifecycle

This foundational workflow isolates development (features or fixes) into short-lived branches off the stable main branch, ensuring the primary branch remains clean and deployable.

• Execution Flow: Developers first pull the latest changes from main to ensure a clean start, then create a new branch for their specific task using git switch -c feature/name.
• Best Practice: Work should be broken down into small, isolated commits within the feature branch, making the subsequent Pull Request review process much easier and cleaner.
• Mechanism: Once development is complete, the branch is integrated back into main (usually via a Pull Request/review), and the feature branch is immediately deleted to reduce repository clutter.

# 1. Ensure clean start and create branch
git pull origin main
git switch -c feature/about-page

# 2. Develop and commit isolated work
# ... create/modify files ...
git commit -m "FEAT: Add initial about page structure"

Key Takeaway: Isolate, develop, review, merge, delete—this cycle keeps main stable.

2. GitFlow Multi-Branch Model

A rigid, complex model designed for projects requiring strict versioning and scheduled releases, utilizing two long-lived primary branches (main and develop) plus three supporting branch types.

• Structure: main holds only production-ready code and is tagged with version numbers, while develop integrates all completed features and serves as the staging branch for the next release.
• Specialized Branches: feature branches are created off develop; release branches are created off develop to stabilize and prepare for production; hotfix branches are created directly off main to patch critical issues.
• GitFlow Overhead: While powerful for managing parallel development and strict versioning, the complexity of merging and maintaining five distinct branch types introduces significant administrative overhead for small, agile teams.

Key Takeaway: GitFlow is ideal for strict versioning but requires high administrative discipline due to its complexity.

3. GitHub Flow Principles

A streamlined, modern workflow centered on the principle that main is always deployable, relying heavily on Pull Requests (PRs) for review and immediate deployment upon merge.

• Core Principle: The single most important rule is that the main branch must pass all tests and be ready for deployment at all times, enabling Continuous Delivery (CD).
• Execution Flow: Developers branch off main, push changes frequently, open a PR early for discussion, and merge only after review and CI/CD checks pass.
• Best Practice: Unlike GitFlow, there are no long-lived develop or release branches; features are merged directly into main, triggering an immediate deployment to production.

Key Takeaway: Simplicity and continuous deployment are achieved by ensuring main is perpetually stable and deployable.

4. Integrating Work via Merging

Merging is the process of integrating changes from one branch into another, which requires careful attention to which branch is currently checked out (the target).

• Execution Flow: To merge changes from a source branch (e.g., feature/about-page) into a target branch (e.g., main), you must first switch to the target branch before executing the git merge command.
• Under the Hood: Git attempts to combine the history of the source branch with the history of the target branch, typically creating a new merge commit unless a fast-forward merge is possible.
• Best Practice: Always ensure the target branch is up-to-date (git pull origin [target]) before merging to minimize the chance of conflicts and ensure you are merging against the latest stable code.

# 1. Switch to the target branch
git switch main
git pull origin main

# 2. Merge the feature into main
git merge feature/about-page

# 3. Clean up the source branch
git branch -D feature/about-page

Key Takeaway: Always switch to the target branch before running git merge [source branch].

Topics Covered in Branching Strategies (Trunk, GitFlow, GitHub Flow)

1. Necessity of Strategies (0:00 - 0:39) — Formal strategies are required because raw Git commands are insufficient for effective team collaboration.
2. Feature Branch Workflow (0:39 - 1:46) — Defines the core lifecycle of isolating work in short-lived branches off the stable main branch.
3. Feature Branch Implementation (1:46 - 3:44) — Demonstrates the practical sequence of commands to create a branch and make isolated commits.
4. Merging and Cleanup (3:44 - 4:46) — Shows the critical steps of switching to the target branch, merging, and deleting the source branch.
5. GitFlow Overview (4:46 - 5:36) — Explains the rigid, multi-branch model suitable for projects with strict versioning requirements.
6. GitHub Flow Overview (5:36 - 6:13) — Outlines the simple, CD-focused model where main is always deployable upon merge.

Git Cheat Sheet

• git switch -c <branch> — Creates and immediately moves to a new branch

  git switch -c feature/about-page
  

• git pull origin main — Updates local main branch with remote changes

  git pull origin main
  

• git merge <source> — Integrates changes from source branch into current branch

  git merge feature/about-page
  

• git branch -D <branch> — Deletes a local branch after it has been merged

  git branch -D feature/about-page
  

• main — Primary, stable, deployable branch in most workflows

Comparison Table

Common Pitfalls

• Mistake: Running git merge while checked out on the feature branch. Avoid: Switch to the target branch (main) first before merging.
• Mistake: Forgetting to delete merged feature branches. Avoid: Use git branch -D <branch> immediately after a successful merge.
• Mistake: Using GitFlow for a small, agile, CD project. Avoid: Use GitHub Flow to reduce administrative overhead and complexity.

FAQs

• What is the difference between main and develop in GitFlow? main holds only production code tagged with versions, while develop is the integration branch for the next release cycle.
• Why is "Main is Always Deployable" so important in GitHub Flow? This rule enforces strict CI/CD discipline, allowing every merge to trigger an immediate, safe deployment to production.
• What is the purpose of deleting a feature branch after merging? Deleting the branch reduces repository clutter and ensures that the branch cannot accidentally be reused for new, unrelated work.