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.

如果您的團隊不接受合并后的代碼審查(因為我們面對現實，因為工具并不真正支持它，這樣就不那么方便了)，請使用短暫的分支，然后在此處應用代碼審查流程。

異議5： 我想查看與任務相關的代碼 (Objection 5: I want to see the code that is related to a task)

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上發布。

翻譯自: https://www.freecodecamp.org/news/why-you-should-not-use-feature-branches-a86950126124/

總結

以上是生活随笔為你收集整理的为什么不应该使用（长期存在的）功能分支的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。