GitFlow工作流下新增功能的分支选择技术咨询

嘿，这个问题刚好踩中了GitFlow分支管理的核心规则，我给你拆解清楚正确的步骤：

第一步：先收尾已完成的bugfix分支 #

你已经修好bug了，别着急开新功能！先把bugfix/bug-name分支合并回**development分支**——这是GitFlow里bugfix分支的标准收尾动作：所有修复的bug都要同步到开发基线，保证development始终是包含所有已完成开发工作的最新分支。

第二步：基于更新后的development开新功能 #

新功能的开发分支（比如feature/new-function-name）必须从刚合并完bugfix的development分支拉取，而不是从bugfix/bug-name分支。

这么做的原因很明确：

• GitFlow的设计逻辑里，development是所有功能开发、bug修复的统一基线，所有新工作都要基于它，避免分支依赖混乱
• 如果从bugfix分支开功能，后续合并时会多一层不必要的分支链路，极易引发代码冲突或者提交遗漏

第三步：发布阶段的合并逻辑 #

等新功能开发完成并合并回development，确认所有要发布的内容都就绪后，再从development分支创建release/x.x.x.x分支。这个分支用来做发布前的最后准备（比如修改版本号、修复发布前的微小问题），完成后：

• 把release/x.x.x.x合并到master分支，给master打上对应的版本标签（比如v1.2.3）
• 同时把release/x.x.x.x合并回development，让开发基线同步发布后的代码

避坑提醒 #

千万别从bugfix分支直接开新功能——这种操作会打破GitFlow的分支层级，后续合并时的复杂度会直线上升，很容易留下代码隐患。

内容的提问来源于stack exchange，提问作者André