擠壓是否會落實到一個最佳實踐中（針對此特定工作流程）？

Question

我有以下git工作流程：

1. 創建新的特性分支
2. 的特性分支工作
3. 經常提交
4. 一旦功能非常齊全，合併到master分支
5. 沖洗和重複

但是，有時候，我有需要從主服務器恢復整個功能。這可能涉及很多revert ing。 （）需要恢復某個功能的原因是我有一個網站可以使用一個回購站，從那裏我們使用一個腳本將站點部署到我們的生產站點或分段站點，兩者都是從我們的主分支完成的。不要問，這就是我曾經接受過的工作，有時候，我正在做一些我要做的事情，但是需要立即做出改變，所以我需要一些方法來按順序進行修改清理回購）

我在想最簡單的方法是如果每個功能分支只有一個提交。然後我可以提交revert。所以很自然，我想在合併到master之前，將特徵分支的所有提交合併爲一個。

所以現在我的工作流程將類似於：

1. 創建新的特性分支
2. 的特性分支工作
3. 經常提交
4. 一旦功能非常齊全git的變基-i HEAD〜number_of_commits （或者如果遠程分支可用，origin/feature_branch）

這個邏輯有什麼問題嗎？它是否違背任何最佳實踐？我自己做了一些測試，整個工作流程似乎順利運行並解決了我的問題，但我想通過其他（更聰明的）Git-ers運行這個想法來查看它是否有任何問題。

謝謝！

Answer 1

您應該考慮利用git的壁球合併功能，即git merge --squash，這樣就不會不必要地重寫歷史記錄。

git merge --squash和git rebase --interactive都可以用於產生一個壓縮的提交與相同的結果工作樹，但它們旨在服務於2個完全不同的目的。你的樹最終會在兩種情況下看起來不同。

初始樹：

a -- b -- c -- d master 
     \ 
     \-- e -- f feature1 

後git checkout master; git merge --squash feature1; git commit：

a -- b -- c -- d -- F master 
     \ 
     \-- e -- f feature1 

git checkout master; git rebase -i feature1後，選擇到pick c和squash d：

a -- b   /-- F master 
     \  /
     \-- e -- f feature1 

你可以從差別看，你做不重寫歷史當使用git merge --squash時，任何分支的結果都會改變，但在使用git rebase -i時，最終會重寫master的歷史記錄。

還要注意的是實際的提交（對於該得到壓扁的）會出現在你的git的歷史在這兩種情況下，只要只能作爲你有一些分支或標記參考通過這些提交可達。

換句話說，在上面的例子，如果你做merge --squash後刪除feature1，你就無法真正查看提交e或f在未來（特別是九十天引用日誌期後）。例子rebase中的提交c和d也是如此。

Answer 2

您的方法的一個具體缺點是它嚴重降低了git bisect在跟蹤代碼中的錯誤方面的效用。

這就是說，如果你發現自己恢復整個功能通常不足以使你正在尋找方法來優化這個過程在哪裏，你可能要問自己是否你歸併到master太快。您可能需要考慮使用多個長期運行的分支來設置更適合您項目的工作流程。