混帳：主/開發/特性分支合併提交

Question

這裏是我下面的流程：

• master分支總是同步的生產
• develop分支總是被釋放
的下一個版本
• feature/feature-name分支是當前正在開發的功能。

特徵完成後，上拉請求從feature/feature-name提升到develop分支，然後從develop分支到主分支。我們在github中完成所有這些工作。

但是，無論何時github上有一個pull請求，這裏就是創建的合併分支。因此，feature/feature-name合併到develop分支後，會創建合併提交; develop branch合併到master branch之後，將創建另一個合併提交。

因此，爲了有1個功能合併，我必須創建2個合併提交。

更糟糕的是，現在主分支和開發分支不再同步，因爲主分支有1個額外的合併提交。

我有兩個問題： 1）我遵循正確的結構/練習嗎？ 2）如何避免額外的合併提交？ ESP。如何保持主分支不會在開發時快速轉發時創建額外的提交？

Answer 1

在我的問題中，似乎有一些誤解，我會嘗試解決。首先，你說

因此，爲了有1個功能合併，我必須創建2個合併提交。

更糟糕的是，現在主分支和開發分支不再同步，因爲主分支有1個額外的合併提交。

是的，你是創建兩個合併提交，但你只能在創建每個分支（develop和master）一個承諾。這就是在Git中合併的方式;當你將一個分支合併到另一個分支時，它會創建一個合併提交。

關於master和develop不同步，如果其他人在將它們合併到develop之前，它們可能不會同步。從功能角度來看，假設自上一次衝刺以來沒有其他人對master進行更改，當您將develop合併到master時，那麼兩個分支應該在功能上等效（儘管其歷史可能看起來不同）。

你問這個問題：

如何保持主分支不會產生額外的承諾時，從快速轉發發展？

如果您develop分支實際上快進master分支，那麼我不認爲你做一個Git合併。但是，如果你不能快進master，那麼解決這個問題的一種方法是手動合併。在這種情況下，合併提交是不可避免的。

如果你真的討厭合併提交，那麼你應該考慮使用rebasing來代替。使用git rebase，源分支始終「保持在目標的前面」，允許您始終將提交快速轉發到目標。

Answer 2

有沒有正確的方式取決於你如何管理分支機構。有些是明智的，有些可能是模塊明智的，有些爲開發人員創建單獨的分支。但關鍵的想法是保持您的本地代碼與master同步並開發分支，並更頻繁地從開發分支中提取更新後的代碼。