SAP 電商雲 UI 持續內建裡 workflow 觸發條件一覽

功能分支是一種源代碼分支模式，其中開發人員在開始處理新功能時打開一個分支。開發人員在此分支上完成功能的所有工作，并在功能完成後将更改與團隊的其他成員內建。

在工作期間，開發人員可能會将團隊其他成員确認的更改合并到自己正在工作的功能分支中，以便在功能完成後減少內建，但直到那時才将更改放入公共代碼庫。這導緻兩個在不同功能分支上工作的人，在第二個人将其工作合并到公共代碼庫之前，不會內建二人的工作。

功能分支是一種流行的技術，特别适合開源開發。它們允許在功能上完成的所有工作在完成之前都遠離公共代碼庫團隊，這允許将合并中涉及的所有風險推遲到真正将功能分支合并到 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!

最佳實踐：避免使用開發周期“過長”的功能分支。

多長算長？

我建議使用功能标志和短期功能分支并練習持續內建。人們選擇使用功能分支的最常見原因是他們希望最大限度地減少釋出不完整或錯誤代碼的風險。但你不應該害怕這樣做。隻要關閉了某個功能，您就可以開始使用了。您可以随時在需要時切換它。我在這裡描述的陷阱是真實的，但這并不意味着你應該完全不使用功能分支。他們真的很有幫助。但這裡的關鍵是他們能活多久。當您不經常釋出時，也會發生同樣的事情。變化不斷累積，等待的時間越長，風險就越大。如果您切換到小批量工作，您可能會繼續使用功能分支，但它們最多隻能存活一天。不同之處在于回報被放大了，您可以快速解決問題，因為沒有太多要審查的内容。這是使用功能分支的聰明方法！