目前在两个分支工作:develop
从开发中创建功能分支，当更改完成时，功能分支然后合并回开发。
目前，我们正在进行一个名为u1的重要更新，该更新将在3个月内完成。与此同时，我们需要为当前版本提供与u1无关的其他功能和热修复。
要完成此更改，我建议如下:
从开发中创建一个新的分支，只包含u1的特性。所有u1相关的特性都将被添加到u1分支中。继续创建热修复程序等，从开发中提取特性分支并合并热修复程序进行开发。在u1功能完成的某个时刻，将u1分支合并到develop(其中包含前面描述的热修复)。这个git策略有名字吗?有没有其他方法来管理这个git工作流?
我遇到的一般做法包括以下规则:
- 有一个
master分支，它相当于生产中的代码 - 有一个
develop分支，它用于阶段和测试功能分支 从 - 当一个特性分支准备好进行测试时，将其合并到
develop - 如果功能分支的测试不成功，那么返回到它
- 如果功能分支的测试成功，那么在部署之前，将其合并到
master - 在部署之前，在
master上进行冒烟测试，也就是说，测试所有可能出错的内容以及至关重要的功能 - 如果冒烟测试失败，确定导致问题的原因并清理
master，只合并没有引起问题的功能 - 如果发烟测试成功，部署
- hotfix分支从
master分支出来，一旦完成合并到master - 如果有一个史诗级的特性分支，就像你描述的那样，然后将它组织成可划分的子任务
- 每个子任务是一个从史诗特性分支中分支出来的任务分支
- 一旦子任务完成，将其合并到您的史诗特性分支
- 冒烟测试史诗功能分支之前，你合并到
develop，然后冒烟测试develop - 永远不要将
develop合并到master中，因为develop可能包含未测试的功能 - 无论何时发生部署，将
master以及您的史诗特性分支合并到develop中
master创建一个特性分支