在gitflow模型中创建修补程序分支或要素分支

我在团队中使用此模型：

今天，我的项目统计如下：

• 稳定版本正在使用master branch在生产中运行
• 我们开发了新的功能，需要在生产前进行测试，因此我们有一个发布分支在SIT环境下进行测试。在SIT环境中进行所有测试后，此新功能可以与master合并

问题：产品所有者在生产表中请求一个新字段。因此，团队提出了两种解决方案：

• 从master创建热修复程序分支，添加新字段并部署到测试环境。此修补程序可以等待数月，直到与master合并，因为在测试通过后我们需要等待产品所有者说可以投入生产，因为此字段取决于其他系统的更改

• 从“开发”创建一个功能分支，并添加此新字段，然后部署到测试环境中我认为这是最糟糕的解决方案，因为我在开发中有一些东西无法合并到master，所以我需要一个樱桃拾取来拾取从发布到master的更改。请记住，团队正在验证SIT环境（发布分支）中的其他功能

---

如果我从开发分支创建功能，我将获得不应该在这个新功能分支中投入生产的功能。请记住，我还不能将开发发送到生产

最大的问题不是合并，而是无法掌握的功能。如何仅发送此更改而不发送开发或发布分支中的所有其他功能

这意味着gitflow不是您的工作流程。
切换到（一个字，）。
更多信息请访问

这种工作流（不将

dev

合并到

master

，但只将功能分支合并到

dev

，然后如果选中，则合并到

master

，以便能够轻松删除未准备好下一版本的功能分支）在Git repo本身中实现

（来源：）

你有：

• master

  分支是否准备好随时部署到生产中：在下一个版本中，将选定的一组功能分支合并到

  master

  中

• dev

  （或集成分支，或“

  next

  ”）是为下一版本选择的功能分支一起测试的分支

• 维护

  （或

  热修复

  ）分支是当前版本演化/错误修复的分支

---

注意：在分布式工作流中，您可以随时提交一些WIP（正在进行的工作）并将其推送到个人分支，而不会出现问题：您可以在将提交内容作为功能分支的一部分之前重新组织（git rebase）。

您的工作流给我留下了深刻的印象，它非常系统化。谈到目前的问题，我觉得你的程序对这种情况仍然适用。如果您的产品为0.2，考虑从第一个黄色点创建一个特征分支（例如，NeXiTable），并将所有部署到生产的热修复合并。这样，当新的_表准备投入生产时，将非常顺利。如果在合并新表之前有更多版本，新表将集成这些更改或将新表迁移到从最新版本创建的另一个功能分支。如果我从开发分支创建功能，我将获得不应在此新功能分支中投入生产的功能。请记住，我不能将development发送到production yetYes，这就是我建议从

第一个黄点创建新的_表的原因，该黄点与主分支提交相同。您将不会得到任何开发更改。好的，但完成后，我将需要合并功能进行开发，我将遇到相同的问题。这是不可避免的，这是新_表而不是SCM的开发人员的责任。开发团队可以有另一个分支与开发分支保持最新，以避免最终出现大的合并冲突。从主节点创建修补程序分支。你认为呢？@RonaldoLanhellas只要你停留在一个模型中，每个分支都应该在下一个模型中合并（功能到开发，开发，发布），你就会遇到“只发送此更改，而不发送开发或发布分支中的所有其他功能”的问题是的，但我的ideia是在完成并测试后从master创建一个修补程序，合并到主机。