Git - Merge vs rebase

Question

但我想確定在這種情況下選擇哪種解決方案：

我想在master上實現一個新功能，所以我將它分支到一個新的Feature分支。
我在功能上做了10次提交，而其他人在Master上做了其他提交。

我的問題是，如果我想將我的分支與Master分開以進行測試，但我需要使用集成的新Master提交來測試它。 那么，我應該將Master合並到Feature（而不是Feature to Master，它會在我的測試之前對master進行修改）或者做一個rebase嗎？

Answer 1

為什么不創建一個新分支來測試合並版本？ 例如：

git checkout -b test-merged-feature master
git merge my-feature
[... do your testing ..]

沒有特別的理由在這里做一個rebase，但如果你還沒有推動你的功能分支，那也沒關系。 這些問題部分是關於你希望你的歷史看起來如何 - 有些人不喜歡看到很多合並; 有些人更喜歡它作為一種跟蹤哪些提交對特定功能有貢獻的方式。

Answer 2

除非你已經推動了你的分支（並且你知道其他人已經克隆了你的回購），我仍然會做一個rebase，正如我在我自己的回答“ git rebase vs git merge ”中提到的那樣。

測試與否，我通常每次更新本地repo（git fetch）時都會進行rebase，以確保最終合並（ Feature to master ）將是一個快速合並。

所以這不僅僅是關於你的歷史看起來如何，而是主要是關於確保你正在開發的東西不是基於舊版本的master ，並且繼續反對隨着時間推移在master身上完成的最新演變。

Answer 3

在我熟悉的工作流程中，有一個主干，集成分支和功能分支

我一直在向'衍生'分支機構進行重組。 （通過衍生分支，我的意思是從主干的AWAY方向），並合並到集成分支。

我喜歡我總是在一個與我將要整合的分支具有相同歷史的分支中工作。 我喜歡合並成為一個快進，因此，我知道我剛剛合並的內容與我剛剛在我的分支中測試的內容完全相同。

Answer 4

當2個開發人員提交相同的repo（這將產生沖突）時，您可以通過創建合並提交來合並2個提交，或者您可以在另一個提交之上重新提交1個提交（您的提交）。 最好更改而不是生成合並提交。