Detailed Explanation and Application Scenarios of Git Flow Workflow¶

When collaborating on projects with multiple developers, code management can be a headache: How to avoid conflicts between different developers’ code? How to ensure the stability of the online version? How to fix urgent bugs without disrupting development progress? In such cases, a clear branching strategy is crucial. Git Flow is a classic branch management solution that addresses these issues.

Why a Branching Strategy?¶

Imagine a scenario where there’s only one branch for the entire project, and everyone commits code to it:
- While developing a new feature, someone might commit a fix for an online bug, potentially causing feature test failures.
- Multiple people modifying the same file will lead to frequent conflicts.
- Rolling back to a previous stable version requires sifting through commit history, which is extremely inefficient.

Git Flow ensures orderly code changes by having different branches with distinct responsibilities, improving development efficiency while reducing the risk of errors.

Core Branches of Git Flow¶

Git Flow defines 5 types of branches, each with a clear purpose:

1. master (Main Branch)¶

• Purpose: Always holds stable, deployable code; the online version must come from this branch.
• Key: Direct modifications to master are prohibited. Updates to master are only allowed via merging other branches (e.g., release or hotfix).

2. develop (Development Branch)¶

• Purpose: The integration branch for daily development, containing the latest development results.
• Key: All feature branches must be merged into develop before integrating into master, preventing the direct contamination of master.

3. feature/* (Feature Branches)¶

• Purpose: Used for developing new features or non-urgent requirements, named like feature/feature-name (e.g., feature/shopping-cart).
• Source: Created from develop and merged back into develop upon completion.

4. release/* (Release Branches)¶

• Purpose: Prepares for version releases, named like release/version-number (e.g., release/1.0.0).
• Source: Created from develop; only bug fixes (no new features) are made here. Merged into master and develop upon completion.

5. hotfix/* (Hotfix Branches)¶

• Purpose: Fixes urgent online bugs, named like hotfix/issue-description (e.g., hotfix/payment-error).
• Source: Created from master; merged into master and develop after fixing.

Complete Git Flow Workflow¶

The branching flow of Git Flow resembles a “production line,” where each branch is created, fulfills its role, and then closed. Here’s the typical workflow:

1. Daily Development: Create feature Branch from develop¶

Scenario: Team develops a new feature (e.g., “Shopping Cart”).
Steps:
- Ensure develop is up-to-date:

  git checkout develop
  git pull

• Create the feature branch:

  git checkout -b feature/shopping-cart

• Develop the feature (e.g., add/remove items) with frequent commits.
• After completion, merge back to develop:

  git checkout develop
  git merge feature/shopping-cart
  git push origin develop

2. Version Release: Create release Branch from develop¶

Scenario: Preparing to release version 1.0.
Steps:
- Create the release branch from develop:

  git checkout -b release/1.0.0

• Test and fix bugs (only bug fixes, no new features):

  # Example: Fix payment calculation error
  git commit -m "fix: Correct payment amount calculation"

• After testing, merge to master and develop:

  # Merge to master and tag for release
  git checkout master
  git merge release/1.0.0
  git tag -a v1.0.0 -m "Version 1.0.0"

  # Merge back to develop to preserve changes
  git checkout develop
  git merge release/1.0.0

3. Urgent Fix: Create hotfix Branch from master¶

Scenario: A critical online bug (e.g., payment module crash) occurs.
Steps:
- Create the hotfix branch from master:

  git checkout -b hotfix/payment-crash

• Fix the bug and commit:

  git commit -m "fix: Resolve payment module crash"

• Merge to master and develop:

  git checkout master
  git merge hotfix/payment-crash
  git tag -a v1.0.1 -m "Version 1.0.1"

  git checkout develop
  git merge hotfix/payment-crash

Application Scenario Examples¶

Example 1: E-commerce “Shopping Cart” Feature Development¶

• Development Phase: Create feature/shopping-cart from develop. After completion, merge back to develop to ensure functionality.
• Release Phase: Once develop stabilizes, create release/1.0.0. If a bug is found (e.g., incorrect cart quantity calculation), fix it in the release branch and merge to master for deployment.

Example 2: Live Streaming Platform Urgent Fix¶

• Online Issue: Live chat messages fail to send (hotfix scenario):
• Create hotfix/chat-fix from master, fix the issue, then merge to master (urgent deployment) and develop (prevent recurrence in future development).

Pros, Cons, and Best Practices¶

Pros:¶

• Clear Structure: Branches have distinct responsibilities, ideal for large teams and projects.
• Version Control: Ensures stable online versions via master and release branches, preventing unfinished code from going live.

Cons:¶

• Slightly Complex: Overkill for small projects or individual developers (requires remembering 5 branch types).
• More Commands: Frequent branch switching and merging may increase conflict risks.

Best Practices:¶

• Branch Naming Conventions: Standardize naming (e.g., feature/feature-name, hotfix/issue-type).
• Test Before Merging: Always test release and hotfix branches thoroughly before merging.
• Simplified Alternative: For personal/small projects, use a simplified Git Flow (only master and feature branches).

Conclusion¶

Git Flow is a structured branching strategy that ensures orderly code changes through clear branch responsibilities. It is suitable for medium-to-large teams and projects requiring strict version control. Beginners can start with the basics (“use feature for daily development, master for online versions”) and gradually incorporate release and hotfix branches. Remember: The core of branching is “isolate changes, merge in order”, not restricting development freedom.