ChatGPT解决这个技术问题 Extra ChatGPT

用 Git 挑选提交是什么意思?

git cherry-pick <commit> 有什么作用?

而不是合并,从一个分支重新提交到目标分支(例如:master)更容易。
有人会说吗?:“Cherry-picking 提交意味着在 HEAD 上创建一个临时分支,将该提交的差异合并到其中,然后快进 HEAD。”或者简单地说:“合并单个提交”。

M
Mike Williamson

Git 中的 Cherry Picking 意味着从一个分支中选择一个提交并将其应用到另一个分支上。

这与 mergerebase 等其他方式形成对比,后者通常将许多提交应用到另一个分支。

确保您位于要将提交应用到的分支上。 git switch master 执行以下命令: git cherry-pick

注意:

如果你从公共分支中挑选,你应该考虑使用 git cherry-pick -x 这将生成一个标准化的提交消息。这样,您(和您的同事)仍然可以跟踪提交的来源,并且可以避免将来发生合并冲突。如果您在提交中附加了注释,则它们不会遵循樱桃选择。要将它们也带过来,您必须使用: git notes copy

附加链接:

git官方指南页面


樱桃采摘真的有必要吗?混合复位或软复位不会做类似的工作吗?
git push 是对 master 进行更改的最后一步
仅供参考:提交在语义上包含当时工作树的所有文件(以及前一次提交的提交哈希),因此您不是将整个提交应用于另一个提交,而是提交对前一次提交所做的更改{ 1} 大多数人倾向于将提交视为更改(就像 svn 是 iirc),但事实并非如此,每个提交都指的是完整的工作树。虽然这在这种情况下没有什么区别,但它可以帮助理解为什么 git 会像它那样工作。
@Zitrax 是不同于提交消息的注释吗?我的单个 git cherry-pick 命令也能够带来我的提交消息。你在说别的吗?我根本不需要运行 git notes 命令来完成它。
@RBT 是的注释与提交消息不同,提交消息跟在cherry-pick 上的提交之后。请参阅git-scm.com/docs/git-notes
A
Amith

此引文摘自:Version Control with Git

使用 git cherry-pick 命令 git cherry-pick commit 应用由命名提交在当前分支上引入的更改。它将引入一个新的、不同的提交。严格来说,使用 git cherry-pick 不会改变存储库中的现有历史;相反,它增加了历史。与通过应用差异的过程引入更改的其他 Git 操作一样,您可能需要解决冲突以完全应用来自给定提交的更改。命令 git cherry-pick 通常用于将特定提交从存储库中的一个分支引入到不同的分支。一个常见的用途是将提交从维护分支转发或反向移植到开发分支。

$ git checkout rel_2.3
$ git cherry-pick dev~2 # commit F, below

https://i.stack.imgur.com/R4nfN.png

https://i.stack.imgur.com/23fCh.png

此外,这里有一个非常好的视频教程:Youtube: Introduction to Git cherry-pick


当在某个分支 (b1) 上进行精心挑选的提交并随后交付给 master 时。如果分支 b1(最初从中选择提交)也尝试交付给 master。冲突如何?这是否得到照顾或它是如何工作的?
@parasrish 是的,他们已经处理了您之前的合并。因此,您确实从 (b1) 分支更改了 a、b、c、d。你樱桃只选了“c”。那么将来一旦你从(b1)合并到master,由于“c”的变化是相同的,它只会合并a,b,d并保持“c”的变化。但是,如果您回滚合并,那么您将返回带有“c”的更改。您将需要单独回滚它们。
需要强调的是:在给出的示例中,只有差 (F - E) 应用于 Z。这是一个狭窄的情况。 Cherry-pick 可用于应用多个提交的差异,例如,两个非相邻提交之间的所有差异。例如,从上面开始,(F - E)、(E - D)、(D - C) 和 (C - B)。这相当于应用差异 (F - B)。
此外,如果选定的 Commit(示例中为 F)有多个直接前任,会发生什么情况?
@j2emanue 换句话说,cherry-pick 只会更改 last-commit。如果您提交 3 次不同的时间,并且如果您选择最后一次,则不会在第一次和第二次提交时进行更改。合并命令将接受您的所有更改并应用于您的目标(主)分支。
A
Aurelio

Git 中的樱桃采摘旨在将一些提交从一个分支应用到另一个分支。如果你可以这样做。犯了一个错误并将更改提交到错误的分支,但不想合并整个分支。你可以只是例如。恢复提交并在另一个分支上挑选它。

要使用它,您只需要 git cherry-pick hash,其中 hash 是来自其他分支的提交哈希。

有关完整程序,请参阅:http://technosophos.com/2009/12/04/git-cherry-picking-move-small-code-patches-across-branches.html


如果底层分支发生变化,导致樱桃挑选没有意义,会发生什么?
D
Daniel Perník

情况的简短示例,当您需要樱桃采摘时

考虑以下场景。你有两个分支。 a) release1 - 此分支将发给您的客户,但仍有一些错误需要修复。 b) master - 经典的 master 分支,例如,您可以在其中为 release2 添加功能。

现在:你在 release1 中修复了一些东西。当然,您也需要在 master 中进行此修复。这是樱桃采摘的典型用例。因此,在这种情况下,cherry pick 意味着您从 release1 分支进行提交并将其包含到主分支中。


你可能只需要另一种方式。您修复了 master 中的一个错误,您应该挑选它来发布 1。它们也可能是存储库而不是分支
为什么不使用合并呢?
我会:从发布创建分支,在分支中修复它,在发布中合并分支,在 master 中合并发布。
我认为这个答案需要解释分支之间的关系:如果 release1 预计稍后会合并到 master 中,那么樱桃挑选(恕我直言)可能没有意义。我猜你还想在挑选完樱桃后重新设置 master1
M
MarianD

我准备了cherry-pick 的分步插图——以及这些插图的动画(接近尾声)。

在挑选之前(我们将从分支功能中挑选提交 L):

启动命令 git cherry-pick feature~2 (feature~2 是 feature 之前的第二次提交,即提交 L):

执行命令后(git cherry-pick feature~2):

https://i.stack.imgur.com/j2D9C.gif

笔记:

提交 L' 从用户的角度来看(提交 = 快照) 是提交 L 的精确副本。

从技术上讲(在内部),它是一个新的、不同的 提交(因为例如 L 包含一个指向 K 的指针(作为其父级),而 L' 包含一个指向 E 的指针)。


这是否意味着,L' 将是 N -> M -> L 在分支 master 上?或者它将专门在主分支上带来提交 L
@PriyankThakkar,是的,完全是 L,没有别的(从图片/动画中可以看到)。
»从用户的角度来看,提交 L'(提交 = 快照)是提交 L 的确切副本。« – 不,它不是同一个快照(除非快照 K 和 E 已经相同),只是相同的差异(即 E→L' = K→L)。
@Paŭlo,您从上下文中提取了这句话,而不是只阅读下一个... :-) 此外,E→L' 和 K→L 的区别是不一样的。
是的,但是 K 的变化也适用,对吧。?
t
theTRON

cherry-pick 是一个 Git 功能。如果有人想将一个分支中的特定提交提交到目标分支,则使用cherry-pick。 git cherry-pick 步骤如下。

结帐(切换到)目标分支。 git cherry-pick 这里的 commit id 是另一个分支的活动 id。例如。 git cherry-pick 9772dd546a3609b06f84b680340fb84c5463264f 推送到目标分支

访问https://git-scm.com/docs/git-cherry-pick


S
SherylHohman

您可以认为樱桃采摘类似于变基,或者更确切地说,它是像变基一样管理的。通过这个,我的意思是它需要一个现有的提交并重新生成它,作为起点,你当前所在的分支的负责人。

rebase 接受具有父 X 的提交并重新生成提交,就好像它实际上具有父 Y 一样,这正是 cherry-pick 所做的。

Cherry pick 更多的是关于如何选择提交。使用 pull(变基),git 隐式地在拉到分支的内容之上重新生成本地提交,但使用 cherry-pick,您显式选择一些提交,并在当前分支之上隐式地重新生成它(它们) .

因此,您执行此操作的方式有所不同,但在幕后它们是非常相似的操作 - 提交的再生。


我发现这是一个非常有用的看待事物的观点。它暗示了为什么 cherry-pick 的行为方式与稍后将目标分支合并回源分支时的行为方式相同。谢谢你,先生。
我想在功能完成后使用cherry pick而不是git merge。每个人在完成一项功能时总是会执行 git merge feature_branch 。为什么不使用cherry-pick 命令?你有什么想法吗?如果我可以挑选,为什么还要费心压缩提交
您可以将变基视为重置和挑选的组合。
@j2emanue 与真正的合并相比,cherry-pick 会将历史记录展平,如果您不注意,这可能会给您中间的非编译代码。与壁球合并相比,它更难使用,因为您需要注意随身携带所有提交。
m
mandelf

它将对您当前的分支应用特定的提交。

这表示 :

将添加此提交添加的所有文件

此提交删除的所有文件都将被删除

此提交修改的所有文件都将被合并。这意味着来自提交的整个文件,而不仅仅是来自此提交的更改!

例如:考虑提交 A

added newFileA
modified main:
+ import './newFileA'

提交 B

added newFileB
modified main:
+ import './newFileB'

如果你在另一个分支上挑选提交 B,你最终会得到:

/newFileB
/main :
   import './newFileA'
   import './newFileB'

由于commit B 包含newFileB 和main,但没有newFileA,导致出现bug,所以谨慎使用。


当然是最有趣的答案,因为它谈论的是重要的文件,而不是整个提交。
这需要更多考虑,樱桃采摘的结果可能会导致危险的路径^^
S
SherylHohman

这有点像复制(从某处)和粘贴(到某处),但针对特定的提交。

例如,如果您想进行热修复,则可以使用 cherry-pick 功能。

在开发分支中执行您的 cherry-pick,并在发布分支中提交 merge。同样,从发布分支到 master 执行 cherry-pick。瞧


W
Wolfack

当您与开发人员团队一起开发项目时,管理多个 git 分支之间的更改可能成为一项复杂的任务。有时您不想将整个分支合并到另一个分支中,而只需要选择一个或两个特定的提交。这个过程被称为“樱桃采摘”。

找到一篇关于樱桃采摘的精彩文章,查看详细信息:https://www.previousnext.com.au/blog/intro-cherry-picking-git


B
Bilal Saidumarov

如果你想在没有提交 ID 的情况下合并,你可以使用这个命令

git cherry-pick master~2 master~0

上面的命令会将 master 的最后三个提交从 1 合并到 3

如果您想为单个提交执行此操作,只需删除最后一个选项

git cherry-pick master~2

这样,您将合并 master 末尾的第三次提交。


这令人困惑。我想你在这里不是master,对吧?当你提到两个提交时,你指的是 提交来定义你想要挑选的范围。正确的?如果描述了场景,将会有很大帮助。不过很好的补充。谢谢。
S
Saikat

摘自官方文档:

给定一个或多个现有提交,应用每个引入的更改,并为每个提交记录一个新的提交。这要求您的工作树是干净的(不修改 HEAD 提交)。当不清楚如何应用更改时,会发生以下情况: 当前分支和 HEAD 指针停留在最后一次成功提交的位置。 CHERRY_PICK_HEAD ref 设置为指向引入了难以应用的更改的提交。干净地应用更改的路径在索引文件和工作树中都会更新。对于冲突的路径,索引文件最多记录三个版本,如 git-merge 的“TRUE MERGE”部分所述。工作树文件将包含由通常的冲突标记 <<<<<<< 和 >>>>>> 括起来的冲突描述。没有进行其他修改。

Read more...