模式很简单：您可以在问题跟踪器中为每个新任务创建一个新分支。任务分支最适合与 Unity 版本控制一起使用，因为它可以轻松处理数千个分支。这种工作流程不是必需的，最终，您必须评估哪种工作流程最适合您的组织。
与只能使用单一分支的传统方法相比，任务分支工作流程能更好地促进并行开发。每个任务都有一个独立的分支，你可以随时从主分支发布任务。
通常情况下，开发人员在提交变更时会非常谨慎，这可能会使变更长期处于源控制之外。任务分支工作流程允许频繁签入，因此您可以随时查看系统内的完整变更历史。
主要分支组织是每任务分支法的目标之一。对进入主分支的所有内容进行严格控制，意味着不会轻易意外破坏构建，因为新的错误会被隔离在任务分支中。
本着 DevOps 的精神，这种工作流程可以缩短任务周期，尽快将新内容投入生产。将软件部署扎根于日常工作中。
该流程从问题跟踪器或项目管理系统中的一项任务开始：Jira、Bugzilla、Mantis、OnTime 或您自己的内部解决方案。这里的关键是，你所做的每一件事都必须有相关的任务。不管是新功能还是漏洞修复，都要为此创建一个任务。
然后，为该任务创建一个分支。
我们建议使用简单明了的分支命名规则：前缀（示例中为 "任务"），后跟问题跟踪器中的任务编号。这可帮助您保持更改的完整可追溯性。
在任务分支上开展工作，并根据需要进行尽可能多的核对。在注释中解释每一个步骤，以便向任何审稿人说明。
任务完成后，将分支的 "状态 "属性设置为 "已解决"。
或者，您也可以在问题跟踪器中将其标记为已完成。这完全取决于您的特定工具集，以及您最终将如何实际执行工作流程。
将任务标记为已完成后，就可以让同事查看。
现在轮到审稿人查看您的改动，看他们能否发现您的编码风格中的错误、不一致之处，或设计中需要修改的地方。如果是这样，任务将重新打开，循环重新开始。
验证是一个可选步骤。
有些团队会对任务进行 "验证"--另一个团队成员会做一个简短的探索性测试，以确保新功能或变更是合理的。他们不会去找漏洞（自动测试已经解决了这个问题），而是从客户的角度来研究变化。可在属性中将状态设置为 "已验证"。
配置您的持续集成 (CI) 系统，以监控具有给定属性集的所有分支。只有当分支达到给定状态（本例中为 "已验证"）时，CI 系统才会考虑该分支。
一旦任务通过审核/验证，任务分支就会在合并到主分支之前自动进行测试。
如果测试套件通过了合并，就会得到确认并提交给 CI 系统进行构建和测试。这一过程有助于防止破坏构建。如果失败，进程将被重启，你将不得不从主程序中重新编译，以解决任何冲突。
如果测试通过，就会签入合并，分支就可以交付了。注意状态已设置为 "合并"。
如果新版本已准备就绪可以部署，就会在 main 上标注新的变更集，并将软件部署到生产环境中。
您可以在每项新任务通过此周期后发布新版本，也可以决定将几项任务归为一组。在实施持续部署时，将每个任务部署到生产中是最合理的工作流程。
有了 Unity 版本控制功能，就可以使用所选 CI 工具（如 Jenkins、Bamboo 或Unity Cloud Build）的插件来配置自动测试和合并步骤。
这一步骤也可以使用 Unity 版本控制的合并机器人功能来协调。mergebot 可以合并这些分支，并触发构建以确保其正常运行。只有在构建良好的情况下，才会确认合并，以避免构建出现问题。
我们喜欢使用以下命名规则：前缀 + 任务编号。例如，分支可以命名为 task1213、task1209 和 task1221。前缀是 "任务"，数字代表相关问题跟踪器中的实际任务编号。
截图还显示了每个分支的描述和编号，因为分支资源管理器是从问题跟踪器中获取编号的。您还可以选择 "显示分支任务信息"，查看分支说明。
Scrum 规则规定，任务时间不应超过 16 小时。这种做法可以控制项目的时间进度。
必须迅速关闭任务分支。理想情况下，你应该有很多小任务，只需几个小时就能完成。这种结构有助于保持项目节奏，促进持续部署。例如，一项大型任务需要持续一周的时间，这就会使循环停止。
有一个红旗要牢记：不要创建 "大砍刀切割 "任务。如果需要将一项任务切割成更小的部分，应确保该任务仍然具有独立的意义，并且可以独立部署。
任务分支工作流程只有得到整个团队的认可，才能取得成功。
与任何 DevOps 流程一样，这一工作流程也包含文化因素。任务分支就是要公开交流进展情况，避免各自为政。在规定工作流程或处理任务的特定方式之前，你需要推动协调。帮助团队成员了解今天完成较大任务中的一小部分的好处，而不是在更大的任务中挣扎更长时间。
问问你自己（或你的队友）：您真的需要刚在任务 1213 中完成的代码来启动任务 1209 吗？
任务往往比你想象的要独立得多。是的，它们可能是同一个主题，但您不需要接触完全相同的代码。您只需添加一些新内容，并相信合并程序会完成其工作。
假设上例中的 1213 和 1209 是错误修正，而不是任务。你不希望一个依赖于另一个。您希望它们击中主屏幕并尽快释放。即使它们接触的是相同的代码，也是不同的修复方法。
每一次核对都必须帮助审核员了解你的思路和过程，从而理解你是如何完成任务的。
在签到的备注中留下详细信息会对审核员有所帮助，因为他们不需要对整个分行进行衍射。取而代之的是逐个变更集进行比较。他们会按照你预先录制的解说，明确每个阶段的任务。他们不会发现自己正在查看一个包含 100 多个修改文件的粗体列表。相反，他们会循序渐进。
每个任务分支完成后都必须准备好进行整合。如果更改很脆弱，或者会使产品表现不佳，那么就不应该将任务设置为已完成。
为了获得自动化带来的好处，这只是一个很小的代价。团队必须就 "完成 "的定义达成一致，即 "为生产做好准备"。作为回报，您可以高枕无忧，因为您知道将您的任务转移到生产中是非常容易的，完全自动化，并且不会导致凌晨 2:00 的消防演习。
什么是功能切换？这些对于持续部署至关重要。这种软件开发技术允许在功能完成并准备发布之前对其进行测试。
功能切换可以在运行时隐藏、启用或禁用该功能。它允许您只为开发团队、少数早期用户或所有人启用某项功能。例如，开发人员可以在测试时启用某项功能，而在开发过程中对其他用户禁用该功能。
我们来看一个例子。您有一个大型功能，分为七个部分，这些部分将被转换为任务，并使用任务分支来实现。如果没有其他准备，怎么可能部署第 4 部分？
第 4 部分可以合并到主分支，甚至可以使用功能切换按钮在隐藏状态下部署。
隐藏并不意味着新代码在发布前不进行测试。当整个功能准备就绪可以启动时，各个部分已经过多次测试。最后一部分的整合不会引发大爆炸式的合并，它只是一个较小的部分进入主部分。
