Git合並 - 壁球還是不壁球？

Question

我目前正在一個相當復雜的開發環境中實現git使用指南，雖然我認為我已經很好地設置了基礎知識，但是有一個問題，特別是我想要一些輸入，如果可能的話。 這不僅僅是一個純粹的技術性問題，因為它更多地是關於哪個可用選項最合適。

基本上，我傾向於一個與常見的“git flow”結構密切相關的系統（ http://nvie.com/posts/a-successful-git-branching-model/ ），除了一些例外，它適用於我們的發展環境。 簡而言之：

• 一個項目至少會有一個'開發'和'主'分支
• 'master'將包含最新的生產就緒代碼
• 'develop'將包含最新的合並代碼
• 其他任何內容都將位於“功能/票證{號碼}”或“修補程序/票證{號碼}”分支中
• 功能分支將來自'develop'，來自'master'的修補程序分支
• 分支名稱中的數字將始終與我們自己的更改/錯誤系統中的票證編號相對應
• 功能可以單獨測試，也可以組合測試，通過構建適當的分支或合並它來“開發”

到目前為止，它確實幫助我們簡化了我們的開發並防止了項目之間的沖突。 這里引發一些爭論的一個細節是; 我們應該使用'--squash'選項將功能/票證分支合並回各自的起源嗎？ 我有點喜歡這個，我喜歡它：

• 用於開發的git日志保持清晰和可讀，所有提交都將簡單地說明原始分支名稱（告訴我們它是修補程序或功能，以及故障單號）
• 即使在清除原始功能或修補程序分支后，合並也不會導致混淆

也許這些原因不會足夠好，也許有充分的理由不在這種情況下使用'--squash'。 有什么想法嗎？

Answer 1

[S]我們應該使用--squash選項將功能/票證分支合並回各自的起源嗎？

這一切都取決於你想要回購歷史的精細程度。 請記住，通過提交消息進行版本控制是一種代碼文檔形式。 不顧一切地碾壓肯定不是好習慣。 它可能適用於修補程序分支，但很少用於實質的功能分支。

作為一個類比，想象一下，如果你問我借給我的Lost DVD盒裝（即你克隆了我的回購），我就給你盒子，沒有DVD，並告訴你

在這里，只需閱讀后蓋上系列的摘要。 這應該告訴你足夠的情節。

所以，當你想要擺脫不必要的詳細或不夠自足的中間步驟時，無論如何都要壓縮你的提交，但是不要掩蓋你的存儲庫的演變。

---

（我在這個Twitter帖子中進一步討論了這個問題。）

Answer 2

不要壓縮：小提交特別適用於以后用git bisect跟蹤bug，無論如何你不想更改歷史記錄。 只需使用合並提交（ git merge --no-ff ）來保持歷史記錄的有序性。