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

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

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

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

多長算長？

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

總結

以上是生活随笔為你收集整理的SAP 电商云 UI 持续集成里 workflow 触发条件一览的全部內容，希望文章能夠幫你解決所遇到的問題。

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