為持久分支合並，變基還是分支？

Question

概念：我有關老爺稱為“核心”的一個分支。

這個分支將永遠存在。

每周一次， 核心需要掌握對母版所做的任何更改。

每月一次，對核心所做的更改需要重新提交至主服務器 。

有時， Core會有像Feature1或Feature2這樣的分支，它們可能存在一兩個月，然后將它們合並到Core中 ，然后刪除功能分支，然后Core將在月末將這些更改推送到master 。

我可以使用rebase或merge進行此操作，也可以在每個月將其合並到master之后創建一個新的核心分支。

我認為最好的方法是每周和每月只使用“合並”，但是我對github並不了解，所以這是正確的方法還是您會預見到任何問題？

          week1    week2     month end
--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o master
  \        \         \         / \
   o--o--o--o--o--o--o--o--o--o---o--o--o--o core
          \              \             /
           o--o--o--o--o--o--o--o--o--o      feature

master由一個大型團隊工作，core有一個小型團隊，一個功能通常是一個人（盡管仍被推送到github進行測試或演示功能），core和master團隊通常不會接觸相同的文件。

Answer 1

您建議的工作流程與Git流程有點相似（另請參閱此備忘單 ）。

關於您的合並與rebase問題，應該注意git rebase是一種破壞性操作（不僅會更改重新提交的SHA1的SHA1，而且源分支中每個提交的代碼庫都可能會編譯，而其中的某些或全部提交在重新設置基准后就不再編譯！）。 相反， git merge將保留兩個分支處的所有提交，並創建一個合並提交，如果需要，可以合並沖突解決方案更改。

git rebase這種“缺點”可能是實際上在實踐中始終使用git merge實現Git流的原因（實際上， git merge --no-ff ，請參見相應的doc ）。

但是，有些團隊可能會選擇不同的工作流來將貢獻集成到master中，每當功能分支和master之間存在某些沖突時（為了獲得更“美麗”的線性歷史記錄），都需要使用git rebase origin/master 。 不過，在這種情況下，建議檢查每個重新基於基礎的提交仍在編譯中（以免妨礙平分 ）。