Git 流程和功能分支的同步

Question

我來自 Perforce，所以請原諒我的初學者問題。 我正在評估 git 及其集成模型。 在 Perforce 中，我有一個master和一個develop分支。 feature1和feature2是支鏈的develop -如此的相似git的流量，但在改變master返回到feature分支，所以圓形的整合模式。

   master-------+-----+
   ⬆           |     |
   +-develop    |     |
     ⬆         ⬇     | 
     +-----feature1-+ |
     ⬆               ⬇
     +------------feature2

這解決了我們 C++ 管道中的一個大問題。 有人將他的功能合並到develop ，讓我們假設由於錯誤解決的沖突等導致編譯器錯誤（由於 8 個不同的目標，開發人員根本無法在本地解決所有問題）。 所以他們提交它，在構建服務器上編譯它並修復遺留的任何問題。 只有在所有平台上都編譯了develop ，更改才會合並到master 。 所以它就像一個安全分支，所以在master沒有任何破壞。 有了這個解決方案，每個開發人員都可以確保從master到他的feature分支的任何集成都是干凈的並且有效。

現在我的問題是，這是如何通過 git flow 實現的？ 功能如何從一個功能分支到另一個功能分支而沒有任何問題？

Answer 1

分行政策

如何只在主分支上運行構建

據我了解，純 git 不提供這樣的功能。 基本上，您可以無限制地將每個提交合並在一起。

然而，您需要的是所謂的分支策略。 這些不是純 git 的一部分，但一些供應商提供它們。 所以這完全是關於在哪里托管你的回購。 我不想為 Microsoft 做廣告，但在我看來 Azure DevOps 正是您所需要的。

這是有關 Azure DevOps git 中分支策略的鏈接。 我推薦關於構建驗證的部分，如果構建成功，它只允許在 master 分支上進行合並。

其他供應商也可能提供這些東西，但我不確切知道，因為我主要使用 Azure DevOps。

Git 分支模型

如何與您的分支機構合作

當談到 git 工作流和分支模型時，有多種方法，每種方法都有優點和缺點。 如果您想繼續使用 Perforce 的分支的基本思想，我會推薦這個分支模型。

關於你的問題

如果“環/循環合並/集成”甚至可能，常見或推薦

我想我可以用“是的，這是可能的和常識，但我不會稱它們為環或圓”來回答這個問題。 網站上提供的分支模型是如何使用合並在分支之間交換信息的一個很好的例子。

結論

• 使用分支策略來保護您的主分支。 只會提交工作代碼。
• 使用分支模型合並分支之間的更改

干杯，祝你好運！