使用“功能分支”与重构兼容吗？ [英] Is using “feature branches” compatible with refactoring?
问题描述
功能分支 是指每个功能都在其自己的分支中开发，并且仅在经过测试并准备发布时才合并到主线中。这样，产品负责人可以选择给定发货中的功能，并在需要进行更重要的工作时停放部分编写的功能（例如，客户打电话给MD投诉）。
"feature branches" is when each feature is developed in its own branch and only merged into the main line when it has been tested and is ready to ship. This allows the product owner to choose the features that go into a given shipment and to "park" feature that are part written if more important work comes in (e.g. a customer phones up the MD to complain).
重构 正在对代码进行转换以改进其设计，从而降低更改成本。如果不不断这样做，您将趋于获得较丑陋的代码库，而这些代码库很难为其编写测试。
"refactoring" is transforming the code to improve its design so as to reduce to cost of change. Without doing this continually you tend to get uglier code bases which is more difficult to write tests for.
在现实生活中，总是有新的客户被出售功能和出于政治目的，所有客户都必须看到其功能组正在取得进展。因此，很少有时间在分支上没有很多未完成的功能。
In real life there are always customers that have been sold new features and due to politics all the customers have to see that progress is being made on "their" group of features. So it is very rarely that there is a time without a lot of half-finished features sitting on branches.
如果进行了任何重构，则合并在功能分支中
If any refactoring has been done, the merging in the "feature branches" become a lot harder if not impossible.
难道我们只需要放弃进行任何重构的能力吗？
另请参见 您如何处理重构与合并需求之间的紧张关系？
这些天来，我的看法是由于政治原因导致了这些长期存在的分支机构，并且由于开发总监的无能使他无法采取行动，所以我应该更快地开始寻找新工作。
推荐答案
功能分支无疑会使重构更加困难。它们还会使诸如持续集成和部署之类的事情变得更加困难，因为您正在增加需要构建经过测试的并行开发流的数量。您还消除了持续集成的中心原则，即每个人都在相同的代码库上工作，并持续将其更改与团队的其余更改集成在一起。通常，在使用功能分支时，不会连续构建或测试功能分支，因此，功能分支代码第一次通过生产构建/测试/部署过程运行是完成并合并进入后备箱。这可能会在开发过程的后期和关键阶段引入很多问题。
Feature branches certainly make refactoring much harder. They also make things like continuous integration and deployment harder, because you are ballooning the number of parallel development streams that need to be built an tested. You are also obviating the central tenet of "continuous integration" -- that everyone is working on the same codebase and "continuously" integrating their changes with the rest of the team's changes. Typically, when feature branches are in use, the feature branch isn't continuously built or tested, so the first time the "feature branch" code gets run through the production build/test/deploy process is when it is "done" and merged into the trunk. This can introduce a whole host of problems at a late and critical stage of your development process.
我持有有争议的观点，认为您应避免在（几乎所有费用）。合并的成本非常高，而且（也许更重要的是）未能持续集成到共享代码库中的机会成本甚至更高。
I hold the controversial opinion that you should avoid feature branches at (nearly) all costs. The cost of merging is very high, and (perhaps more importantly) the opportunity cost of failing to "continuously integrate" into a shared code base is even higher.
场景中，您确定每个客户的功能都需要一个单独的功能分支吗？您是否可以在后备箱中开发这些功能，但在准备就绪之前将其禁用？通常，我认为最好以这种方式开发功能-将它们检入主干，即使它们尚未投入生产，也应将其保留在应用程序中，直到准备就绪为止。这种做法还鼓励您使组件保持良好的结构，并在设计良好的接口后面加以屏蔽。 功能分支方法为您提供了在代码库中进行全面更改以实施新功能的借口。
In your scenario, are you sure you need a separate feature branch for each client's feature(s)? Could you instead develop those features in the trunk but leave them disabled until they are ready?. Generally, I think it is better to develop "features" this way -- check them in to trunk even if they aren't production-ready, but leave them out of the application until they are ready. This practice also encourages you to keep your components well-factored and shielded behind well-designed interfaces. The "feature branch" approach gives you the excuse to make sweeping changes across the code base to implement the new feature.
这篇关于使用“功能分支”与重构兼容吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
