问题标签 [cherry-pick]

在手册页中 git cherry-pick：

是否有配置设置可以在本地将默认设置回-x，并允许-r禁用它？我找不到，但我可能错过了。

我有时想从不同的存储库中选择一系列提交。我知道有两种方法可以做到这一点。

1.

或者

2. git rebase --onto myBranch begin end

我发现第一个版本更容易记住。然而，我读了很多关于挑选樱桃与合并相比是多么邪恶的文章，因为它有点打破了历史。但是我还没有弄清楚的是，在挑选一系列提交或使用 rebase 之间是否有区别--onto

我倾向于认为应该没有区别。我弄错了吗？

在我想要cherry-pick从分支 B 到分支 A 的提交之一中，有四个文件发生了更改，但我只希望该提交中的一个文件位于分支 A。如何在分支 A 上获取该文件？谢谢！

最近在我们所有的存储库中，我们向所有存储库添加了一个 git 属性文件。这个想法是强制在所有文件中使用 Unix EoL 字符。这在您结帐到新分支的第一天产生了巨大的问题，它开始显示整个文件中的更改。我们只是承诺了。

现在，问题是如果我们从一个分支合并到另一个分支（我们经常这样做）或cherry-pick（我们做更多），合并会再次在所有文件中显示冲突。

如果 git 可以通过首选项忽略行尾或空格更改，那将是理想的。有谁知道 git 是否包含类似的东西或者是否有解决方法？

可能是一个基本问题。我已经在分支中挑选了一些提交。现在我想获得一个从分支 A 提交到分支 B 的提交列表。有没有办法做到这一点？

我正在编写代码，我发现自己的情况与此博客中解释的情况相似。基本上，我有两个版本的代码，它们使用完全不同的容器。这样做是为了比较使用不同容器时代码的效率。因为我依赖于高效的容器成员函数，所以我无法使代码相对于容器通用，所以我选择了一种方法，其中有两个 git 分支：一个用于优化代码，另一个用于未优化代码。

问题是在我优化了一部分代码之后，我需要在两个现在不同的分支上做一些共同的工作。是否可以在“上游”（非优化）分支上完成工作，然后在不解决很多冲突的情况下挑选优化分支的常见提交？

我按照网上找到的教程，创建了一个带有单个文件（以测试冲突）和一些分支的虚拟存储库。

对于这个 git 存储库示例，是否可以在不解决冲突的情况下将分支“秒”上的提交“02 秒”放入主分支？我不反对解决冲突，但如果可以避免，我很感兴趣。

在这种情况下正确的工作流程是什么？我应该应用常见的更改，提交，樱桃挑选+解决冲突，就是这样吗？

I'd like to cherry-pick single commits from on branch to another. I expect file renames to be quite common but still want to be able to apply changes without human intervention.

Since the built-in cherry-pick command doesn't seam to detect renames (at least in my test cases), especially when combined with modification to the renamed file.

I tried a bit and finally came up with a solution involving two rebase operations.

Let's assume I have a branch named target pointing at the commit I want to apply the cherry-pick to. The commit I want to cherry-pick is pointed to by a branch named source.

I then execute the following commands:

1. create branch sourceTemp pointing at the same commit as source (since I want to retain the branch source )
2. git rebase --strategy="recursive" --strategy-option="rename-threshold=30" target sourceTemp (maybe use another threshold; the test file was quite small and the changes therefore relatively large)
3. git rebase --onto target sourceTemp~ sourceTemp

This applies only the changes introduced by the last commit in branch source to target.

I also put my test on github:

https://github.com/fraschfn/cherry-pick

What I like to know is, if this approach is feasible or if it only worked in my simple test setting!

Update: Alternative method

I rebase the patch to the merge base of source and target:

start situation

I want to cherry-pick D onto B.

1. rebase D onto M after creating a new branch patch

   /li>

2. merge C and D' to obtain a replacement for source

   merge B and D' to obtain the patched version of target

   /li>

The advantage is that E and F can now be merged without a problem. Alternative way: Include the patch as early as possible in the hierarchy thus not creating D but directly D' and saving yourself the rebase.

The advantage above the previous version is that you can merge the two branches "new source" and "patched target" and it will work (if the merge of source and target would work of course) and not introduce the same changeset twice since git knows due to the merge operation which introduced the changeset into both branches.

git shortlog便于制作人类可读的更改摘要。但是，当我从主分支中挑选更改时，我使用该-x标志，git cherry-pick因为它记录了它选择的提交。这会导致短日志中的一些丑陋：

有没有一种简单的方法可以告诉git shortlog我们不想要那些精选的行（在实际日志中的新行上）？

当然，我知道可以将它们过滤掉，例如使用git shortlog Version-3.5.3..3.5 | sed 's/[(]cherry picked.*$//g'. 但似乎git应该知道自己的注释并能够处理它们。我错过了什么？

我遵循这个部分地用 git 挑选提交 来挑选仅对某些文件的更改。

在挑选之后，一些文件发生了冲突，即文件有如下部分：

通常使用 git merge，我使用我心爱的 p4merge 来解决冲突，非常直观且无错误。

但是使用cherry-pick，当我使用git mergetool时，它说不需要合并，尽管文件<<<<<<中有。所以我不得不手动编辑和解决冲突。

那么我怎么能让 git 知道存在冲突呢？

谢谢杨

这是我的场景：

假设我想修复 github 上的一个开源项目。在高层次上，我遵循以下工作流程：

• 在 github 上 fork 源项目
• 在本地克隆叉子
• 从 master 创建一个主题分支
• 进行修复（在这里挥手无关的细节......）
• 将主题分支推送到 github
• 向原始源项目提交拉取请求

好的，现在假设我已经这样做了几次，所以我有名为 issue#123 和 issue#456 的主题分支。原源项目，除了master分支，还有release分支，比如1.0、1.1等。

我有自己的独立项目，使用这个开源项目的 1.1 版。我不想针对开源项目的“大师”进行构建，因为它还不稳定。我需要的是开源项目 1.1 分支的本地构建，其中还包括我对问题#123 和问题#456 的修复。

很抱歉设置冗长......无论如何，我目前正在做的是创建一个名为 my-1.1 的本地分支（从 1.1 分支），从我的主题分支中挑选修复程序，然后构建它并使用结果我独立的、依赖的项目。

我不是 100% 肯定樱桃采摘是正确的方式，但合并似乎不正确，因为我不希望 master 的所有 1.1 后更改（它们存在于我的主题分支中）流入“my-1.1”分支。这是最好的方法吗？有什么需要注意的问题吗？

我能想到的唯一另一种方法是为每个修复创建重复的主题分支，一个在 master 的分支中，一个在 1.1 的分支中。然后我可以将基于 1.1 的主题分支合并到 my-1.1 中，而不是从基于主的主题分支中挑选提交。但这似乎是个大麻烦。