罗振宇和罗永浩长谈9个小时: 创业者八个重要关系

Git Flow is a branching model that provides a structured workflow for managing software development. 1. It uses two main branches: main for production-ready code and develop for integrating features. 2. Feature branches (feature/feature-name) are created from develop and merged back after completion. 3. Release branches (release/vX.X.X) are spawned from develop to prepare production releases, then merged into both main and develop, with version tagging. 4. Hotfix branches (hotfix/issue-name) are created from main to quickly address production bugs and merged back into both main and develop. This model ensures stable releases, supports parallel workflows, and enhances version control, making it ideal for teams with versioned releases, though it may be overly complex for continuous delivery environments.

Git Flow is a popular branching model designed to help development teams manage code changes efficiently, especially in projects with regular releases. Introduced by Vincent Driessen in 2010, it provides a clear structure for handling feature development, bug fixes, and releases—making collaboration smoother and reducing the risk of breaking production code.

At its core, Git Flow defines specific branches for specific purposes, each with a well-defined role and lifecycle. Here’s how it works.

Main Branches: main and develop

Git Flow relies on two long-lived branches:

• main (or master): This branch always reflects a production-ready state. Every commit on main is a potential release, often tagged with version numbers (e.g., v1.0.0).
• develop: This is the main branch where integration of all features happens. It contains the latest delivered changes intended for the next release.

All feature work starts from develop and eventually gets merged back into it.

Supporting Branches: Features, Releases, and Hotfixes

In addition to the main branches, Git Flow uses several types of short-lived branches for different workflows.

1. Feature Branches

• Purpose: Isolate development of new features.
• Branch from: develop
• Merge back into: develop
• Naming convention: feature/feature-name

You create a feature branch when starting new work:

git checkout -b feature/user-login develop

Once the feature is complete and tested, merge it back into develop:

git checkout develop
git merge feature/user-login
git branch -d feature/user-login

This keeps ongoing development isolated and stable.

2. Release Branches

• Purpose: Prepare a new production release. This is where final polishing happens—bug fixes, documentation, version bumping.
• Branch from: develop
• Merge back into: develop and main
• Naming convention: release/v1.2.0

When the team decides it’s time to release, a release branch is created:

git checkout -b release/v1.2.0 develop

During this phase, only minor fixes are allowed. No new features. Once ready:

git checkout main
git merge release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git checkout develop
git merge release/v1.2.0  # Bring changes (like version bump) back
git branch -d release/v1.2.0

This ensures main and develop both have the correct updates.

3. Hotfix Branches

• Purpose: Quickly fix a critical bug in production.
• Branch from: main
• Merge back into: main and develop
• Naming convention: hotfix/critical-bug

If a bug is found in production, you don’t wait for the next release:

git checkout -b hotfix/login-bug main

After fixing and testing:

git checkout main
git merge hotfix/login-bug
git tag -a v1.2.1 -m "Hotfix login issue"
git checkout develop
git merge hotfix/login-bug
git branch -d hotfix/login-bug

This gets the fix out fast and ensures it’s included in future development.

Why Use Git Flow?

• Clear roles: Everyone knows where to work and what each branch means.
• Stable production: The main branch stays clean and release-ready.
• Parallel workflows: Features, releases, and hotfixes can happen simultaneously without interference.
• Better version control: Tags and structured merges make rollbacks and audits easier.

That said, Git Flow adds complexity. For smaller teams or continuous delivery setups, simpler models like GitHub Flow might be more appropriate.

Git Flow isn’t the only way to manage branches, but it’s a solid choice for teams that release software in versions and need strong control over what goes live. With proper tooling (like Git extensions or CI/CD integration), it can streamline collaboration and reduce deployment stress.

Basically, it’s structure for sanity—especially when things get busy.

The above is the detailed content of An Introduction to the Git Flow Branching Model. For more information, please follow other related articles on the PHP Chinese website!