當我使用Git時，我應該在合併之前重新綁定？

我正在開發一個大型的Rails項目，我正在使用的團隊正在使用Github來管理項目。雖然許多變化都在本地進行，然後直接推送到我們的開發分支，但是當我們要進行非常大的變更時，我們創建了一個分支。當將分支合併到開發中時，我經常嘗試在我的特性分支合併到開發中（以防止覆蓋其他人的工作）之前將其重新開發回我的特性分支。我發現當我這樣做時，我似乎碰到了兩次相同的合併衝突。在重新綁定時，我遇到了一系列衝突，然後在合併時再次遇到衝突列表。在將我的特性合併到開發中之前，我是否應該將其轉換爲我的特性分支？還是應該將我的特性合併到開發中？當我使用Git時，我應該在合併之前重新綁定？

比方說，我的功能分支被稱爲「new_feature」。我用了「開發」分支合併它的過程是這樣的：

git checkout develop 

git pull (this is set up on our rig to always pull rebase) 

git checkout new_feature 

git rebase develop 

(lots of merge conflicts ensue) 

git checkout develop 

git merge -no-ff new_feature 

(same set of merge conflicts again)

這是因爲如果時間軸從我的底墊發生變化引起我的新特性分支，以一種反射鏡開發沿原路回來，再製定衝突與自己的psudo副本。

來源

2012-02-02 Code Junkie

爲什麼'git merge -no-ff'？如果你剛剛重新發展新功能，它應該是一個快速發展。 – Useless 2012-02-02 18:03:32

我真的不確定。有一段時間，我們在這裏有一個真正認識Git的人，他告訴我，我應該這樣做，因爲某種原因，這與清理時間表有關。我不知道原因是什麼。 – 2012-02-02 18:06:43

我可以看到它可能會使時間線混淆......嗯。 rebase將替換'new_feature'上的所有提交，並將相同的更改應用於'develop'而不是原始分支點，這意味着您將獲得（提交）舊提交的副本，其父項（在原始分支點和「開發/ HEAD'）比他們年長。 – Useless 2012-02-02 18:15:53

好吧，現在評論太長了。

後第一次運行rebase套用說明書（git help rebase）

Assume the following history exists and the current branch is "new_feature": 

       A---B---C new_feature 
       /
      D---E---F---G develop 


    From this point, the result of either of the following commands: 

     git rebase develop 
     git rebase develop new_feature 

    would be: 

         A'--B'--C' <new_feature 
         /
      D---E---F---G <develop

現在，如果你有衝突，實際狀態將

   A'--B'--C'--[local state] 
      / ^
D---E---F---G   new_feature 
      ^develop

其中[local state]是你還沒有發生衝突的合併修理。一旦你解決合併衝突，並且增加了解決文件索引，在運行git rebase --continue：現在你的狀態將會

   A'--B'--C'--H <new_feature 
      /
D---E---F---G <develop

顯然，在這一點上合併new_feature返回到發展可快進，像這樣：

   A'--B'--C'--H <new_feature <develop 
      /
D---E---F---G

，但如果它不是你會得到這個代替

   A'--B'--C'--H <new_feature 
      /   \ 
D---E---F---G---------------I <develop

現在的這些無論你從喜歡時間表的角度來看，這不是一個明顯的原因，爲什麼會有一個問題...除非你從來沒有完成rebase和解決與H衝突，但我會認爲git會抱怨。

來源

2012-02-02 20:03:13 Useless

「但如果不是，你會得到這個」？「不是」什麼？我不明白如何導致這兩種情況。有什麼區別？ – Umagon 2017-09-18 14:04:01

「_...可以被快速轉發......但是如果它不是......_」。如果您選擇不使用「--no-ff」快進合併，您將得到合併提交，而不是像圖中所示的那樣移動分支指針。如果你首先不瞭解任何一種情況，那麼你可能需要問自己的問題或者學習更多關於git的知識，因爲我無法真正猜出這個答案在哪裏丟失了你。 – Useless 2017-09-18 15:06:14

聽起來對我來說，就像你正在向後使用rebase，但它可能只是一個令人困惑的措辭。

我想將特徵分支重新分配到開發然後（在開發中）做一個git merge --ff-only feature。

來源

2012-02-02 17:44:16 madth3

我正在編輯我的帖子以顯示該過程，看看我是否弄錯了。 – 2012-02-02 17:52:45

由於@Useless評論說，合併應該是一個快進（我更喜歡用--ff-only來強制它）。儘管你用文字表達它的方式並不是標準，但其餘的都是好的。我建議閱讀http://progit.org/book/ – madth3 2012-02-02 18:14:35

-1

由於您在同一個問題中指定了「大規模」和「基準」，我建議您不要這樣做。改用合併。

在合併中使用--no-ff對於保留原始分支點非常有用。我支持使用它。

來源

2012-02-02 20:05:01

當我使用Git時，我應該在合併之前重新綁定？

回答

相關問題