问题标签 [cherry-pick]

假设我在存储库文件夹中有一组提交......

我想获得一份工作副本，其中包括从修订版 117 开始的所有更改，但不包括修订版 118 和 120 的更改。

编辑：为了使问题更清楚，我想撤消在 118 和 120 中所做的更改，同时保留所有其他更改。该文件夹包含数百个子文件夹中的数千个文件。

实现这一目标的最佳方法是什么？

感谢 Bruno 和 Bert，答案是命令（在这种情况下，用于在执行完全合并后删除 120）

请注意，必须使用前导减号指定修订号。“-120”不是“120”

假设我是一个 repo 的维护者，并且我想从贡献者那里获取更改，有一些可能的工作流程：

1. 我cherry-pick每次都从远程提交（按顺序）。在这种情况下，git 将提交记录为与远程分支无关。
2. 我merge是分支，拉入所有更改，并添加一个新的“冲突”提交（如果需要）。
3. 我merge从远程分支单独提交每个提交（再次按顺序），允许为每个提交记录冲突，而不是全部组合在一起。
4. 为了完整起见，您可以做一个rebase（与cherry-pick选项相同？），但是我的理解是这可能会给贡献者造成混淆。也许这消除了选项1。

在情况 2 和 3 中，git 记录提交的分支历史记录，与 1 不同。

cherry-pick使用所描述的任何一种或merge方法之间的优点和缺点是什么？我的理解是方法 2 是规范，但我觉得通过单个“冲突”合并解决大型提交并不是最干净的解决方案。

我在远程存储库（origin/master）中有提交，我想将其放入从该存储库（origin/remote_branch）创建的分支中。

当我结帐到那个远程分支时

然后挑选我所做的提交

当我尝试推送时，git 会说一切都是最新的。

有什么我做错了吗？

In Mercurial/TortoiseHg, given the following example, what is the easiest way to merge revision "G" into repo A without taking D,E and F (Assume that G has no dependency on D,E or F).

Is a patch the best bet?

我有两个分支。Commita是一个的头部，而另一个有b, c, d,e和f在a. 我想在没有提交的情况下移动c,d和e到f第一个分支b。使用cherry pick 很容易：逐个签出第一个分支cherry-pickc并将f第二个分支重新设置到第一个分支上。但是有没有办法在一个命令中挑选所有c？f

这是场景的视觉描述（感谢JJD）：

我想从一个分支挑选到另一个分支，但他们分歧很大。如何获取修改文件给定部分的提交列表？

我有一种感觉，我在问一些在 git 中无法完成的事情，但我不妨问一下。有什么方法可以让我进行一次更改并将其提交给所有分支？例如，假设我想更改我的 AUTHORS 文件或 LICENSE 文件。我知道我可以将更改提交到一个分支，然后将其单独挑选到每个分支。但是有没有更简单的方法呢？

我现在是唯一一个使用 git 的人，其他人都在使用 svn。我已经使用 'git svn' 连接到团队 svn，而且大多数情况下它工作得很好。最近，我最初自己开始了一个项目，单独的 git repo，现在我需要将其中的东西合并到 svn。但是，我仍然想在发布之间继续调整我自己的隐私实现。

那么，从我的私人仓库中挑选一些提交到 svn 克隆仓库的最直接的方法是什么？要求是保留完整的本地历史记录，并且每个选择只有一个 svn 提交。还是有一些挤压要做？

作为实现这一点的一种方法，有没有办法让私人回购作为 svn 克隆回购的另一个来源？

我们公司目前正在使用一个简单的主干/发布/修补程序分支模型，并希望就哪些分支模型最适合您的公司或开发过程提供建议。

1. 工作流/分支模型

   以下是我所看到的对此的三个主要描述，但它们之间存在部分矛盾，或者不足以理清我们遇到的后续问题（如下所述）。因此，到目前为止，我们的团队默认的解决方案不是那么好。你在做更好的事情吗？

   • gitworkflows(7) 手册页
   • (nvie) 一个成功的 Git 分支模型
   • (reinh) 敏捷团队的 Git 工作流

2. 合并与变基（纠结与顺序历史）

   是否应该pull --rebase等待合并回主线，直到您的任务完成？就我个人而言，我倾向于合并，因为它保留了任务开始和完成的视觉说明，我什至更喜欢merge --no-ff这个目的。然而，它还有其他缺点。许多人还没有意识到合并的有用属性——它不是可交换的（将主题分支合并到主分支并不意味着将主分支合并到主题分支）。

3. 我正在寻找一个自然的工作流程

   有时会发生错误，因为我们的程序没有使用简单的规则捕捉特定情况。例如，早期版本所需的修复当然应该基于足够的下游，以便可以将上游合并到所有必要的分支中（这些术语的使用是否足够清楚？）。然而，在开发人员意识到它应该被放置在更下游的地方之前，一个修复程序会使其成为主控器，如果它已经被推送（更糟糕的是，合并或基于它的东西），那么剩下的选项就是樱桃采摘，与其相关的危险。你使用什么样的简单规则？这还包括一个主题分支的尴尬，它必然排除其他主题分支（假设它们是从一个公共基线分支的）。开发人员不想完成一个功能来启动另一个功能，感觉就像他们刚刚编写的代码已经不存在了

4. 如何避免创建合并冲突（由于樱桃挑选）？

   似乎创建合并冲突的可靠方法是在分支之间进行挑选，它们永远不能再次合并？在任一分支中应用相同的提交恢复（如何做到这一点？）可能会解决这种情况？这是我不敢推动很大程度上基于合并的工作流程的原因之一。

5. 如何分解成局部分支？

   我们意识到从主题分支组装一个完整的集成会很棒，但是我们的开发人员的工作通常没有明确定义（有时就像“四处寻找”一样简单），如果某些代码已经进入“杂项”主题，根据上面的问题，它不能再次被带出那里吗？您如何定义/批准/毕业/发布您的主题分支？

6. 像代码审查和毕业这样的适当程序当然会很可爱。

   但是我们根本无法让事情变得足够解开来管理这个 - 有什么建议吗？集成分支，插图？

以下是相关问题的列表：

• 有哪些好的策略可以让已部署的应用程序可修复？
• 内部开发使用 Git 的工作流程描述
• 用于企业 Linux 内核开发的 Git 工作流程
• 您如何维护开发代码和生产代码？（感谢这个PDF！）
• git 发布管理
• Git Cherry-pick vs 合并工作流
• 如何挑选多个提交
• 如何使用 git-merge 合并选择性文件？
• 如何挑选一系列提交并合并到另一个分支
• ReinH Git 工作流程
• 用于进行修改的 git 工作流，你永远不会推回原点
• 樱桃选择合并
• 组合操作系统和私有代码的正确 Git 工作流程？
• 使用 Git 维护项目
• 为什么 Git 不能将文件更改与修改后的父/主合并。
• Git 分支/变基良好实践
• “git pull --rebase”什么时候会给我带来麻烦？
• 大型团队如何使用 DVCS？

还可以查看 Plastic SCM 写的关于任务驱动开发的内容，如果 Plastic 不是您的选择，请研究nvie 的分支模型和他的支持脚本。

鉴于两个分支已经分歧，并且需要将来自一个分支（而不是所有内容）的特定提交引入另一个分支， git cherry pick 正是实现了这一点。

一段时间后，需要将两个分支完全合并。git 如何知道它已经拥有过去挑选的提交，这样它就不会重新引入它？