功能分支是一种源代码分支模式，其中开发人员在开始处理新功能时打开一个分支。开发人员在此分支上完成功能的所有工作，并在功能完成后将更改与团队的其他成员集成。
在工作期间，开发人员可能会将团队其他成员确认的更改合并到自己正在工作的功能分支中，以便在功能完成后减少集成，但直到那时才将更改放入公共代码库。这导致两个在不同功能分支上工作的人，在第二个人将其工作合并到公共代码库之前，不会集成二人的工作。
功能分支是一种流行的技术，特别适合开源开发。它们允许在功能上完成的所有工作在完成之前都远离公共代码库团队，这允许将合并中涉及的所有风险推迟到真正将功能分支合并到 develop 分支之时。但是，这种隔离确实会阻止及早发现问题。更严重的是，它还不鼓励重构 - 缺乏重构通常会导致代码库的健康状况严重恶化。
使用功能分支的后果在很大程度上取决于完成功能所需的时间。通常在一两天内完成功能的团队能够足够频繁地进行集成，以避免延迟集成的问题。需要数周或数月才能完成一项功能的团队将遇到更多关于合并分支时遇到的冲突问题。
The Pitfalls of Feature Branching
本文谈谈在开发工作流程中使用功能分支的一些陷阱。
You’ll Waste Time Fixing Unnecessary Merge Conflicts
合并冲突是使用功能分支的最大陷阱。没有什么比花费不必要的时间修复合并冲突更伤人的了，尤其是当一个功能分支已经存在一段时间时。但时间并不是唯一的因素。删除任何现有代码或引入新问题的风险会大大增加。在某些情况下，您还需要在稳定所有代码的同时冻结代码中的任何更改。团队中参与的每个人都必须确保删除或覆盖任何代码。与远程团队一起工作时，我感受到了这种痛苦。他们总是删除我最近的更改。每次他们更改某些内容时，我都必须停止正在做的事情并查看他们的工作，以查看我的代码是否被更改——甚至一起删除。我不怪他们。我们只有一个用于大型单体应用程序的代码存储库。相反，我归咎于合并冲突。当有太多人在同一个源代码存储库中工作时，您可能需要将代码解耦。将您的大应用程序分成更小的部分，以避免合并冲突带来的痛苦。有些人可能会将此称为从单体应用到微服务，但这并不意味着您将为两个或三个文件创建一个 git 存储库。
You’ll Have No Consistency When Generating Artifacts
当您生成将在您的环境中部署的工件时，建议您只生成一次。构建和打包应该在您的工作流程或交付管道的第一阶段进行。第一阶段通常是开发。在生产环境中发布更改时，您不希望得到任何惊喜。出于这个原因，最好在任何地方都以相同的方式部署，包括生产。配置的变化就是您所期望的。分支可能听起来不错。通过这种方式，您可以将准备就绪的更改与尚未准备就绪的更改隔离开来。但是让我们考虑一个常见的场景：您拥有“dev”、“controller”和“release-X”分支，并且每个人最初都将他们的更改推送到“dev”分支。到达那里的所有内容都在开发和任何其他测试环境中发布。当更改准备好发布时，您创建一个“release-bugfix”分支并生成工件。发布后，您可以将更改集成到“控制器”，因为所有稳定代码都存在于此。问题是每个人都需要从“控制器”更新他们的分支并解决任何冲突。自他们上次更新以来可能已经过去了很长时间。但不仅如此。他们需要再次生成工件，并且还需要重新通过测试集。它增加了交付时间和风险，并且您将失去一致性。
You Won’t Be Ready To Ship
应该发布哪个功能分支？有不止一个吗？应该先去哪个？这些是您在使用功能分支时将面临的问题类型。如果您不知道答案，则需要花一些时间进行调查。而且不仅如此。您还需要与在某些分支上工作的团队进行协调，以确保没有人删除另一个人的代码。错误修复怎么样？如果您需要推送更改但您正处于合并过程中怎么办？或者，如果您在管道中间有一个尚未准备好发布的分支？事情即将变得复杂。为了确保您不会发布任何意外，您需要提前回滚以便有一个清晰的路径。只有这样，您才可以为修复创建另一个分支。这听起来可能太复杂了，但我已经多次看到这种情况。还有一些像 GitFlow 这样的分支模型可以帮助你解决这个问题。但可悲的是，复杂性并没有消失，破坏事物的机会仍然存在。 GitFlow 可能对处理代码的其他人有害。分支模型需要如此复杂这一事实表明您的工作流程需要有所改变。这些类型的问题会降低发布节奏。
Feedback and Collaboration Will Be Complicated
当您使用功能分支时，在合并分支之前，团队将不知道发生了什么变化。反馈不会很快到来。协作被牺牲了，因为该小组只关注他们在功能分支中更改的代码片段。为了避免任何延迟，有些人甚至可能决定在完成编码之前不更新他们的分支。花时间决定应该混合或删除哪些代码也会导致延迟。所有这些加起来就是拖延。人们知道修复合并冲突会影响他们的交付时间，所以他们决定把它留到最后。这里的另一个缺点是，在某个时间点，两个功能分支可能存在共同问题。每个团队都会以不同的方式解决它。因此，代码可能会开始重复。对同一问题的解决方案可能不止一种。出现问题时，您会修复哪一个？你都知道吗？还是只是某些人？你永远不会确切地知道。这就是为什么将您的更改推送到“控制器”将增加团队中的反馈和协作的原因。您收到的反馈是即时的。团队被迫更频繁地拉取最新的变化。如果存在冲突，他们可以轻松查看刚刚更改的内容，而无需在合并分支时查看大量更改。当在每个合并请求中需要仔细检查一长串文件时，就会出现问题。当开发人员将最新更改推送到主分支并确保它不会影响其他人的工作时，这样会更好。但这需要尽快发生。
Knowing What Changed Will Be Difficult
在功能分支中可能会发生很多事情。 如果有不止一个人在做它，最可能的情况是每个人都有一个来自功能分支的分支。 最有可能的是，在合并功能分支时会发现许多提交消息。 你可以压缩你所有的提交，让它们看起来像一个，但是如果代码需要被审查，做它的人将需要阅读大量的内容。 他们会有问题……太多的问题。 尽管总有一种方法可以让您回顾历史并查看进行了哪些更改，但在决定在修复合并冲突时应该选择哪些代码时，最好能快速了解为什么该代码是添加、删除或更改。 了解上下文将是关键。
In Short, Avoid Using Long Feature Branches!
最佳实践：避免使用开发周期“过长”的功能分支。
多长算长？
我建议使用功能标志和短期功能分支并练习持续集成。人们选择使用功能分支的最常见原因是他们希望最大限度地减少发布不完整或错误代码的风险。但你不应该害怕这样做。只要关闭了某个功能，您就可以开始使用了。您可以随时在需要时切换它。我在这里描述的陷阱是真实的，但这并不意味着你应该完全不使用功能分支。他们真的很有帮助。但这里的关键是他们能活多久。当您不经常发布时，也会发生同样的事情。变化不断累积，等待的时间越长，风险就越大。如果您切换到小批量工作，您可能会继续使用功能分支，但它们最多只能存活一天。不同之处在于反馈被放大了，您可以快速解决问题，因为没有太多要审查的内容。这是使用功能分支的聪明方法！
