Git 分支與 Git 分叉

Question

我有一個普遍的疑問。 假設有一個以 master 分支作為開發分支的 git repo，並且您想在不影響 master 分支的情況下進行一些更改，然后您想稍后合並它。 更好的方法是什么？

1. 在同一個 repo 中創建新分支，然后將其合並到 master。
2. 通過分叉創建新的 repo，然后將其合並到 master。

Answer 1

如果您確定最終會與主分支合並和/或您的更改相對較小（錯誤修復，新功能），那么一定要創建一個新分支。 僅當您要進行可能成為新項目的巨大更改時才進行分叉。 這是我遵循的經驗法則（因為它遵循 git 的基本項目設計元數據），所以我希望這會有所幫助。

Answer 2

我強烈建議在同一個存儲庫中創建一個新分支。 您在這個新分支中完成您的工作，直到新功能完成。 最終完成后，將其合並回 master。 這遵循了 git 的設計。

它真的沒有分叉。 只有原版的克隆。 您創建的克隆越多，事情就會變得越復雜，並且您需要對拉取請求做更多的工作才能將更改返回到原始存儲庫。

Answer 3

對於“公共”協作和實驗來說，分叉可能是一個非常好的模式，但是當預期的用例是許多人朝着一個統一的目標努力時，分支往往更適合

因此

選擇選項 #1) 分支- 如果您在團隊中一起工作並開發軟件。

選擇選項 #2) fork - 如果您要為任何開源項目做出貢獻。

Answer 4

我建議以下策略。

1. 大師 --> 生產部署之一和所有來源：

2. 開發 --> 始終與 Master 同步

   • 功能/分支。
     • 具有功能/分支基礎的多個開發人員分支。
       • 將 PR 提升到功能/分支。
     • 一旦在功能/分支上完成了功能開發和測試，創建 PR 以開發用於 UAT/SIT 測試的分支。
   • 錯誤修復/分支。

3. 開發/分叉-->這個分支應該總是與開發同步。 您可以通過在 Bitbucket Server 上標記“啟用強制同步”來啟用此功能。

   • 生產錯誤修復/分支。
     • 一旦錯誤修復完成，將 PR 提升到開發/分叉分支。
     • 將develop/Fork 分支部署到UAT/SIT。
     • 然后提出 PR 來開發以合並錯誤修復更改。