一千萬個為什麽

搜索

Git cherry pick和datamodel完整性


鑒於兩個分支已經分歧並且需要將一個分支(而不是所有分支)的特定提交引入另一個分支,git cherry pick就是這樣。

一段時間後,需要完全合並兩個分支。 git如何知道它已經過去曾經提交的提交,以便它不會重新引入它?

最佳答案

避免重復提交 tonio的答案中提到的文章說:

想象一下,我們有主分支和分支b:

  o---X   <-- master
   \
    b1---b2---b3---b4   <-- b

現在我們迫切需要master中的提交b1和b3,而不是b中的剩余提交。所以我們做的是檢查主分支和櫻桃選擇提交b1和b3:

$ git checkout master
$ git cherry-pick “b1’s SHA”
$ git cherry-pick “b3’s SHA”

結果將是:

  o---X---b1'---b3'   <-- master
   \
    b1---b2---b3---b4   <-- b

假設我們在master上做了另一次提交,我們得到:

  o---X---b1'---b3'---Y   <-- master
   \
    b1---b2---b3---b4   <-- b

如果我們現在將分支b合並到master中:

$ git merge b

我們會得到以下結果:

  o---X---b1'---b3'---Y--- M  <-- master
   \                     /
     b1----b2----b3----b4   <-- b

這意味著b1和b3引入的更改將在歷史記錄中出現兩次。為了避免這種情況,我們可以改變而不是合並:

$ git rebase master b

哪會產生:

  o---X---b1'---b3'---Y   <-- master
                       \
                        b2---b4   <-- b

最後:

$ git checkout master
$ git merge b

給我們:

  o---X---b1'---b3'---Y---b2---b4   <-- master, b

此主題之後)


OP在評論中添加:

但似乎我還不太明白rebase是如何工作的......我的意思是即使在變基之後不應該仍然會出現櫻桃挑選的提交?

不可以。 git commit 手冊頁明確提到:

如果上遊分支已包含您所做的更改(例如,因為您郵寄了上遊應用的補丁),則會跳過該提交。< BR>   例如,在以下歷史記錄中運行git rebase master(其中A'和A引入相同的更改集,但具有不同的提交者信息):

      A---B---C topic
     /
D---E---A'---F master

將導致:

               B'---C' topic
              /
D---E---A'---F master

您可以使用 git cherry master 檢測主服務器上是否已存在提交(如果您在主題分支上)。

轉載註明原文: Git cherry pick和datamodel完整性

猜你喜歡