Git cherry pick和datamodel完整性

Question

鉴于两个分支已经分歧,并且需要将一个分支(而不是所有内容)的特定提交引入另一个分支,git cherry pick就是这样.

一段时间后,需要完全合并两个分支.git将如何知道它已经过去曾经提交过的提交,以便它不会重新引入它？

Answer 1

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

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

现在我们迫切需要master中的提交b1和b3,而不是b中的剩余提交.所以我们做的是检查master分支和cherry-pick提交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 rebase master(其中A'和A引入相同的更改集,但具有不同的提交者信息):

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

将导致:

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

您可以检测master上是否已存在提交git cherry master(如果您在topic分支上).

Answer 2

你可能想读

Git Cherry-pick vs Merge Workflow在merge和cherry-pick之间进行了很好的比较,特别是那个cherry-pick不存储父id,因此不会知道它已经提交了过去的樱桃,所以它不会重新介绍它.

和