git rebase和共享功能分支？

Question

基於此： https : //www.atlassian.com/git/tutorials/rewriting-history/git-rebase

git rebase可以保持線性歷史記錄（“總是”合並將產生快進）

但是，如果我要強制執行線性歷史記錄並要求開發人員始終將其功能分支基於最新的master進行開發，是否不會導致協作/共享功能分支消失在窗外？ 看到：

不要重新建立公共歷史

那么是否可以使用git rebase強制執行線性歷史記錄，並同時允許多個開發人員為同一功能分支做出貢獻？

還是git rebase暗示一個功能分支只能有一個所有者？

Answer 1

“不要以公共歷史為基礎”是一個很好的入門規則。 更全面的建議是，如果要重新建立共享分支的基礎，則需要擁有副本的每個人的協議/合作。

（在這一點上，通常有人喜歡進入並反對有時不讓所有人同意的做法。他們試圖說的是規則太嚴格；但這就像說光速太慢，因為我需要更快地旅行。正確的分析是，是的，有時您無法讓所有人參與進來；在那種情況下，您不應該根據基准進行簡化，因此簡化的“請勿根據公共歷史進行分類”。共享分支機構的每個人的合作，對分支機構進行重新設置是不安全的，而您嘗試這樣做的結果很容易最終被意外撤消。但是我離題了……）

因此，如果按照團隊規范， 在人們與分支機構進行協作之后 ，並且准備好合並它，就需要重新建立基礎，並且每個人都將丟棄其分支機構的本地副本，那么就可以了-你們與基地的每個人都有合作。

但這並不一定意味着它是個好主意。 用於rebase的市場營銷文獻喜歡將線性歷史稱為“簡單”，但是卻忽略了閃亮的新線性歷史主要是由從未測試過的代碼狀態組成的（這可能會使bisect bug搜尋bisect 。） 一些項目在保留提交拓撲方面具有價值，因此，例如，他們可以將特征分支作為一個單元進行回顧，而不必僅僅確定一次提交K到N恰好是一個功能分支。

但是，這一切都取決於您/您的團隊。 如果您認為線性歷史記錄很適合您，那么是的，即使共享了功能分支也可以做到，只要您在合並后仍將其丟棄（這...為什么不呢？）。

Answer 2

對的，這是可能的。 盡管建議一定謹慎。

使用該基礎，將功能分支更改添加到主開發線。 這應該在審閱后發生（在GitLab / GitHub中：在接受合並/拉取請求之后）。 因此，以前的開發並不一定涉及任何較早的基礎。 功能分支可能已由多個開發人員共享，使用和提交。

不要重新建立公共歷史

這通常意味着您不應該將其他人可能基於其工作的提交作為基准（例如， master或develop公共存儲庫的分支）。 由於沒有人應該將他們的工作建立在尚未完成但尚未合並的功能分支上，因此這不適用於您的情況。

Answer 3

我認為您的問題源於擁有一個中央git存儲庫而不是私有fork的常見工作流程。 在該遠程存儲庫上，所有分支都可以從所有開發人員處推送。 正因為如此，每個開發人員都可能會感到有能力去推動和合並他們想要的任何東西。 有了這樣的工作流程，由於開發人員可能會由於強制推送刪除提交而意外刪除已經推送的提交，因此git rebase確實會變git rebase危險。

如果你有這樣的牛仔git的工作流程正在進行，那么它可能是明智的建議開發者使用--force-with-lease ，而不是僅僅--force 。

我認為協作和共享功能分支走出窗口是一件好事。

在我團隊的主要遠程git存儲庫（真相的來源）中，我擁有了master分支，可以防止rebase。

我建議這些規則：

• 總是從master派生功能分支，沒有例外
• 再次：永遠不要派生另一個要素分支的要素分支
• 如果您依賴於另一個開發人員當前正在開發的另一個功能，請等待他們將這些更改合並到主版本中。
• rebase對你的特性分支master頻率（包括你的依賴，或只保留主最新的），因為它有助於解決合並沖突，因為它們發生
• 可選：將您的提交壓縮為一個，如果您使用git web-frontend（github，bitbucket等），則它們提供了合並壁球的Pull Request的功能，您可能也想使用它

創建分支的開發人員擁有該分支。 他們可以做任何想做的事情：刪除，重新設置基礎，進行探戈合並，在該分支上與其他人進行配對編程（其他人可能仍會在其分支上進行承諾，但只有在所有者明確同意和知識的情況下）。

主要分支（例如master或develop ）是公共分支。 他們是聖潔的。 您無需更改其歷史記錄，並且可以保護它們免遭刪除以及它們的歷史記錄不被覆蓋。 如果您需要撤消主分支上的功能，則可以使用revert 。

Answer 4

我建議您鼓勵 （而不是強制執行）線性歷史記錄，方法是要求開發人員在同行評審之前的最后一步，將其功能分支重新建立基礎。

在最終重寫歷史記錄之前，這將允許開發人員進行協作，交叉合並並對該功能感到滿意，從而使審閱者易於閱讀。

當然，這仍然存在重新建立公共歷史的風險，並且可能給那些不太熟悉這種做法的開發人員帶來問題。 這就是為什么我會鼓勵那些適應它但不執行它的人改基礎。