Git - 合併vs rebase

我看了一下When do you use git rebase instead of git merge? 但我想確定在這種情況下選擇哪種解決方案：我想在Master上實現一個新功能，所以我將它分支到一個新的特色分支。我在功能上做了10次提交，而其他人在主設備上進行了其他提交。Git - 合併vs rebase

我的問題是，如果爲了測試目的，如果我想讓Master與Master分開，但我需要使用集成的新主Master提交進行測試。因此，我應該將主人合併到功能中（而不是將功能合併到主人中，在我測試之前將主人的修改應用到主人身上）還是進行重做？

來源

2013-05-02 user2316341

這就是辯論。我會做一個rebase。 – 1615903 2013-05-02 10:45:19

您查看的鏈接中的最佳答案提供了一個明確的建議，以便在您的用例中進行重定位。 – mah 2013-05-02 10:47:55

未來，請使用更多描述性標題，以更清楚地解釋您嘗試解決的問題。 – 2014-07-31 19:09:33

爲什麼不創建一個新分支來測試合併版本？例如：

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

沒有什麼特別的理由，在這裏做一個重訂，但如果你還沒有推你的特性分支，我不會有事的爲好。這些問題部分是關於你希望你的歷史看起來如何 - 有些人不喜歡看到很多合併;有些人更喜歡將其作爲跟蹤對特定功能作出貢獻的方式。

來源

2013-05-02 10:45:59

我想有一個「開發」分支來測試功能，然後把它放在主人的生產將是一個很好的做法，在這種情況下？所以合併VS rebase問題只是關於你想要提交歷史的方式？ – user2316341 2013-05-02 11:30:32

我同意這個選項（合併在一個新的分支），所以+1。但我仍然在下面的答案中主張進行重新分配。 – VonC 2013-05-02 11:31:11

@ user2316341如果您必須整合（合併）幾個Feature分支以查看它們是否一起工作，那麼「dev」分支是有意義的。但是，如果您一次只有一個功能分支...它增加了一點收益的複雜性。 – VonC 2013-05-02 11:34:14

除非你已經被推您的分支（你知道其他人克隆你的回購協議），我還是會做一個變基，我在自己的「git rebase vs git merge」答覆中提到。

測試與否，我通常會在每次更新本地回購（git fetch）時進行重新綁定，以確保最終合併（Feature到master）將是一個快速向前的合併。

因此，這不僅僅是關於您的歷史外觀，而是主要確保您開發的內容不是基於舊版本的master，並且隨着時間的推移繼續與master中的最新變化。

來源

2013-05-02 11:29:08 VonC

所以你說我應該總是在大部分時間做rebase，但是如果我已經推動了我的分支，那就不行了。這是爲什麼？已經推動分支的問題是什麼？ – user2316341 2013-05-02 11:54:03

@ user2316341 rebase重寫SHA1的歷史記錄。在這種情況下，你必須'git push --force'來替換已經由rebase生成的新歷史記錄推送的歷史記錄。如果沒有人使用你的分支，這不是什麼大問題，並且rebase是迄今爲止最簡單和最安全的解決方案，而不是人工合併中間分支。 – VonC 2013-05-02 11:56:35

@ user2316341請參閱http://stackoverflow.com/a/8940299/6309作爲問題的示例。 – VonC 2013-05-02 11:57:32

在工作流程我熟悉，有一個主幹，並集成分支（S），並設有分支機構

我一直對「衍生」分支rebaseing。（通過派生分支，我指的是從幹線開始的方向），並且合併到整合分支。

我喜歡這種感覺，我總是在一個分支中工作，這個分支與我將要整合的分支具有相同的歷史。我喜歡合併成爲快進，所以，我知道我剛剛合併的內容與我剛剛在分支中測試的內容完全相同。

來源

2013-07-23 18:01:12

當2個開發人員提交相同的回購（這會產生衝突）時，您可以通過創建合併提交來合併2個提交，或者您可以在其他提交之上重新提交1個提交（您的）。最好重新綁定而不是生成合並提交。

來源

2015-10-07 10:51:08

Git - 合併vs rebase

回答

相關問題