为什么不应该使用（长期存在的）功能分支

Isn’t the git history in the picture above nice to work with? There are probably many problems in that repository, but one of them is most definitely the use of feature branches. Let’s see how such a bad thing became such a common practice.

上面图片中的git历史不是很好用吗？该存储库中可能存在许多问题，但其中之一无疑是功能分支的使用。让我们看看如何把一件坏事变成如此普遍的做法。

When git came to replace SVN it brought a ridiculously easy way to create branches.

当git取代SVN时，它带来了一种创建分支的简单方法。

The idea behind git is to ease your pain as a developer working on many features at a time. Not to push branches around and tie them to the whole development process of your team.
git的想法是减轻开发人员同时处理许多功能的痛苦。 不要四处推销，不要将分支与团队的整个开发过程联系在一起。

When JIRA and others came along, companies like Atlassian started to promote the “git workflow” and feature branches heavily. The “Create branch” button appeared in your JIRA tasks and boom, feature branches were born! Atlassian tells you all about it in this interesting article. I like Atlassian’s products very much. Keep in mind though that their core business is tasks management for development teams. The more tangled it gets with branches and code, the better.

当JIRA和其他公司出现时，像Atlassian这样的公司开始推广“ git工作流程”并大力推广分支机构。 “创建分支”按钮出现在JIRA任务和繁荣中，要素分支诞生了！ Atlassian在这篇有趣的文章中向您介绍了所有相关信息。我非常喜欢Atlassian的产品。请记住，尽管他们的核心业务是开发团队的任务管理。与分支和代码的纠缠越多，越好。

Ten years later, feature branching is a standard in most teams, when in fact it doesn’t bring any benefits to your bottom line: release quality software to production. Not only do feature branches provide zero benefits, they actually slow you down!

十年后，功能分支成为大多数团队的标准，而实际上却没有给您的底线带来任何好处：将高质量的软件发布到生产环境中。功能分支不仅提供零收益，而且实际上会使您减速！

For the sake of clarity: this article assumes a feature branch will carry the whole feature you are developing and is a so-called ‘long-lived’ feature branch that will last 1 week or more. It’s not a “no branches at all” mantra.

为了清楚起见：本文假设功能分支将包含您正在开发的全部功能，并且是所谓的“长寿命”功能分支，它将持续1周或更长时间。这不是“根本没有分支”的口头禅。

“The feature is ready. I just need to merge it!”

“该功能已准备就绪。我只需要合并它！”

I’ve heard this way too many times. This falls in the same category as statements like “It compiles so it works”.

我听过这么多次了。这与“它可以编译因此起作用”这样的语句属于同一类别。

In practice, the merging leads to the “unpredictable release syndrome”. It can be quick or evince a major incompatibility, which needs fixing in a rush. You are either lucky or … your timeline shifts and code quality drops.

实际上，合并会导致“不可预测的释放综合症”。这可能是快速的，也可能是主要的不兼容性，需要立即解决。您要么幸运，要么……您的时间表发生了变化，代码质量下降了。

The real problem with feature branches is the reason they are so popular: they pump a developer’s pride and make you feel good about your work.
功能分支的真正问题是它们如此受欢迎的原因：它们激发了开发人员的自尊心，并使您对工作感到满意。

Your feature branch is your own perfect garden and you can keep it clean and shiny. But it is separated from the other gardens of your team. The more you work apart, the harder it is to reconcile.

您的功能分支是您自己的完美花园，可以使它保持清洁和光泽。但是它与团队中的其他花园分开了。您的工作越多，调和就越困难。

I am a big fan of the management book “The goal”. It shows how over time people tend to use metrics that highlight local optimums of a process because it is more comfortable. They just lose focus on their global bottom line. The book is about a production plant, but the analogy stands. Your feature branch is a local optimum with high-quality code. It may also be so far off the main branch that it is of no use for the upcoming release.

我是管理书籍“目标”的忠实拥护者。它显示了随着时间的流逝，人们会倾向于使用强调流程局部最优的指标，因为它更舒适。他们只是失去了对全球底线的关注。这本书是关于一个生产工厂的，但比喻是正确的。您的功能分支是具有高质量代码的局部最优。它也可能离主要分支太远，以至于即将发布的版本都没有用。

基于主干的开发进行救援 (Trunk based development to the rescue)

As the name suggests, in trunk based development the whole team pushes continuously to the main branch or use very short-lived (1 or 2 days max) branches.

顾名思义，在基于主干的开发中，整个团队会不断推向主分支，或者使用寿命很短(最长1或2天)的分支。

Here is a detailed description of the idea. I have no affiliation with the linked website. It is just a great overview of the concept.

这是该想法的详细描述。我与链接的网站没有任何隶属关系。这只是对该概念的一个很好的概述。

When you push your work to the main branch on every push, the amount of code to merge is way smaller and it becomes trivial. There is a far greater benefit though: you and your team can spot problems before they become painful. It might be that your refactoring clashes with another feature. Or you are drifting off from the project conventions or architecture patterns. This is the real value of the process. As I preach in any place I find myself in:

当您每次将工作推送到主分支时，要合并的代码量要小得多，并且变得微不足道。但是，这样做还有更大的好处：您和您的团队可以在问题变得痛苦之前就发现问题。您的重构可能与其他功能冲突。或者，您正在偏离项目约定或体系结构模式。这是过程的真正价值。当我在任何地方宣讲时，我发现自己处于：

It is teamwork that makes or breaks software projects.
团队合作决定了软件项目的成败。

Working days on code that will never get to the release on time is the biggest failure there is for a team.

对于团队来说，最大的失败是无法按时发布代码的工作日。

Another upside of pushing to the main branch is that your changes will run live in some environment. It is always good to deploy and battle test your code, even in progress, in some real deploy.

推送到主分支的另一个好处是您的更改将在某些环境中实时运行。在某些实际部署中，即使在进行过程中，部署和测试代码始终是一件好事。

异议1：主分支中的“ WIP”！ (Objection 1: “WIP” in the main branch!?!)

If you read so far you are probably thinking “This is crazy, how can I push my half done work to the main branch when it will probably get deployed to production very soon!?!”.

如果到目前为止，您可能会想：“这太疯狂了，当半完成的工作可能很快就会部署到生产环境时，我该如何将其完成的工作推到主分支！

Here are the common objections one might have and a tentative solution.

以下是一个人可能遇到的共同反对意见，并提出了一个临时解决方案。

异议2：我无法完成未完成的工作！ (Objection 2: I can’t expose unfinished work!)

Use feature toggles. They can be environment variables or whatever suits you best to turn on and off your work in progress. Make it defensive of course so your half-finished code does not get active in production by mistake.

使用功能切换。它们可以是环境变量，也可以是最适合您打开或关闭正在进行的工作的任何变量。当然要使其具有防御性，这样您半完成的代码就不会错误地投入生产。

Your whole team will love this: you can activate the code on any environment at any time to see how it looks or performs. Testers can prepare to test early on. Product owners can comment on your work along the way. It is all live and easy to access for everyone! If your work is just started, this provides little value. But evil lies in the details. It usually takes half the time to get to 90% completion and another half to finish the remaining 10%. Sharing your work in this state of 90% completion is always a good idea ;)

您的整个团队都会喜欢这一点：您可以随时在任何环境下激活代码，以查看其外观或性能。测试人员可以准备尽早进行测试。产品负责人可以对您的工作进行评论。一切都是实时的，所有人都可以轻松访问！如果您的工作刚刚开始，那么它的价值就很小。但是邪恶在于细节。通常需要一半的时间才能完成90％的工作，而另一半则需要完成剩余的10％的工作。在90％的完成状态下分享您的作品总是一个好主意;)

Another thing that comes for free: you can turn the feature off in production if a problem arises after deployment. After a few days or weeks, once the feature runs smoothly, just remove the toggle from the code.

免费提供的另一件事：如果在部署后出现问题，则可以在生产中关闭该功能。几天或几周后，一旦功能正常运行，只需从代码中删除切换开关即可。

异议3：如果我打破所有人的主要分支怎么办？ (Objection 3: What if I break the main branch for everyone?)

It is 2019. If you don’t have a continuous integration setup that builds and runs tests automatically … then set it up yesterday. If you break anything you’ll be notified before it becomes a problem for the whole team.

现在是2019年。如果您没有可自动构建并运行测试的持续集成设置，请昨天进行设置。如果您破坏了任何内容，则会在整个团队遇到问题之前得到通知。

In pure Trunk Based Development the feedback will come after the merge and has to be fixed right away. If you are using short-lived branches the merge should be blocked by your CI tool. A short-lived branch is something that should last 1 or 2 days max and carry a consistent piece of code that contributes to the feature you are building.

在纯基于主干的开发中，反馈将在合并之后出现，必须立即修复。如果您使用的是短暂的分支，则CI工具应阻止合并。寿命短的分支最多应持续1或2天，并带有有助于构建功能的一致代码段。

异议4：我们合并之前必须进行代码审查！ (Objection 4: There must be a code review before we merge!)

That’s a valid point. Code reviews do not need feature branches though. If the code review culture is strong in your team then it can very well be done on the commit to the main branch. The reviewer would stop by the author of the commit and discuss what needs to be fixed. The fix would come in another commit. Even better, have the code review together before pushing the commit in the first place.

这是有道理的。代码审查虽然不需要功能分支。如果您的团队中的代码审查文化很强，那么可以很好地完成对主分支的提交。审阅者将停止提交的作者，并讨论需要解决的问题。该修复程序将在另一个提交中进行。更好的是，在首先提交提交之前，将代码重新审核。

If it is not acceptable to your team to have post-merge code reviews (because let’s face it it is less handy as tools do not really support that), use short-lived branches and apply your code review process there.

如果您的团队不接受合并后的代码审查(因为我们面对现实，因为工具并不真正支持它，这样就不那么方便了)，请使用短暂的分支，然后在此处应用代码审查流程。

If you have a given branch per feature then it is easy to track code back to your agile board. You can navigate from a task to the branch that implements it.

如果每个功能都有给定的分支，则可以很容易地将代码追溯到敏捷板。您可以从任务导航到实现该任务的分支。

It sounds cool, while in reality, this is useless! How many people can you have on an agile team? Up to 5? Up to 10? How hard is it to ask the person running a task or story what commits you need to look at to deep dive into the implementation?

听起来很酷，但实际上这没用！您在敏捷团队中可以有多少人？最多5个？高达10？问执行任务或故事的人有多难，而您需要深入研究实现以了解什么？

After some time, once tasks are completed for a long time, linking tasks to code does not make sense anymore. Developers rely on git blame to know the who, on code content to know the how, and hopefully on comments to know the why.

一段时间后，一旦任务长时间完成，将任务链接到代码不再有意义。开发人员依靠git blame来了解谁，依靠代码内容来了解如何，并希望依靠注释来了解原因。

蛋糕上的樱桃：选择加入新功能 (The cherry on the cake: opt-in on new features)

It became common to see major UI features or updates released using an “opt-in” approach. Github, Bitbucket, Gmail, … to name a few.

看到主要的UI功能或使用“选择加入”方法发布的更新已经很普遍。 Github，Bitbucket，Gmail等…。

The concept is that major changes are introduced using a banner “Hey we have this new feature / improved dashboard / whatever. Click here to try it out”. You can opt-in, and usually opt out as easily if you don’t like the change. This is a very good adoption testing strategy as it involves the end users in the decision process. If people opt-in and stay there it means you are improving the experience. If they opt in and out … you know you’ve changed things for the worse.

其概念是使用横幅广告进行重大更改。“嘿，我们有这个新功能/改进的仪表板/任何东西。单击此处进行尝试”。您可以选择加入，如果您不喜欢更改，通常选择退出也很容易。这是一个非常好的采用测试策略，因为它使最终用户参与了决策过程。如果人们选择加入并留在那里，则意味着您正在改善体验。如果他们选择加入和退出……您知道您已经变得更糟了。

If you are using feature toggles from the start, exposing these on a per-user basis at run time becomes very easy.

如果从一开始就使用功能切换，则在运行时按用户显示这些功能切换将非常容易。

结论 (Conclusion)

If you never thought of trunk based development as an alternative to the feature branch mantra, I hope this article gave you some perspective and that you will to try it out.

如果您从未想到过将基于主干的开发替代功能分支的口头禅，那么我希望本文能为您提供一些观点，并且您可以尝试一下。

The best thing is that to get there you’ll need to setup or improve every other aspect of your process (CI, automated tests, code reviews). This is a good path to take. We obviously recommend Fire CI as a continuous integration tool.

最好的事情是，要到达那里，您需要设置或改进流程的其他每个方面(CI，自动化测试，代码审查)。这是一条好路。我们显然建议将Fire CI作为持续集成工具。

Remember that your bottom line is to put quality software in front of your users. The closer your code is from the production environment at all times, the better.

请记住，您的底线是将优质软件摆在用户面前。在任何时候，代码离生产环境越近越好。

Now, although the article is very much “trunk based development” oriented, note that it might not be a valid approach for your team.

现在，尽管本文非常注重“基于中继的开发”，但请注意，对于您的团队而言，这可能不是有效的方法。

If your team is highly distributed, in different time zones, has a lot of junior developers who need to learn the project conventions and architecture, using longer-lived feature branches might work better.

如果您的团队分布在不同的时区，并且有很多初级开发人员需要学习项目约定和体系结构，那么使用寿命更长的功能分支可能会更好。

The main idea in this article is:

本文的主要思想是：

The faster you integrate the different pieces together and check that things are working, the safer you are to have a working product at the end.

您将不同的部件集成在一起并检查一切是否正常的速度越快，最后获得可用产品的安全性就越高。

A good common ground is to use short-lived branches that last 1 or 2 days max and merge them to the main branch. This way you can humanly control what gets in and still integrate code fast.

一个好的共同点是使用寿命最长不超过1或2天的短期分支，并将它们合并到主分支中。这样，您可以人为地控制内容并仍然快速集成代码。

Thanks for reading! If you find the article useful please hit the clap button below. It would mean a lot to me and it helps other people see the story!

谢谢阅读！ 如果您发现该文章有用，请点击下面的拍手按钮。 这对我来说意义重大，而且可以帮助其他人看到这个故事！

Originally published at fire.ci on March 30, 2019.

最初于2019年3月30日在fire.ci上发布。