注意：这是我这边的一个错误。我精心挑选了父哈希。请参阅update部分。
原始问题：
我在分支"test_imu"中vmu_hw_test了一个文件，其更改类似于如下所示
if( g_imu_spi.readFromFifo() == 0)
{
//Find local maxima and minima event
g_imu_spi.compute_event();
//compute the euler
g_imu_spi.compute_euler();
//From the average values compute the max
//g_imu_spi.compute_Max();
g_imu_spi.compute_Max(buffer);
}
if声明和删除注释是在此提交中引入的。master分支有
//Find local maxima and minima event
g_imu_spi.compute_event();
//compute the euler
g_imu_spi.compute_euler();
//From the average values compute the max
g_imu_spi.compute_Max(buffer);
问题
1.正如我所读到的cherry-pick接受单个提交更改并应用它。如果分支不同(在提交历史记录中(
是否有问题 2.一份Microsoft文件说不要挑选樱桃。采摘樱桃是一种不好的做法吗？
3. 为什么樱桃采摘会失败？(更新：它没有。
Git 差异
对于test_imu.c上的最新提交
diff --git a/Src/vmu_hw_test.c b/Src/vmu_hw_test.c
index 14b0a67..1954d64 100644
--- a/Src/vmu_hw_test.c
+++ b/Src/vmu_hw_test.c
@@ -2694,14 +2694,16 @@ unsigned short IMU_sendData(void)
}
}
//Regular run
- g_imu_spi.readFromFifo();
- //Find local maxima and minima event
- g_imu_spi.compute_event();
- //compute the euler
- g_imu_spi.compute_euler();
- //From the average values compute the max
-// g_imu_spi.compute_Max();
- g_imu_spi.compute_Max(buffer);
+ if( g_imu_spi.readFromFifo() == 0)
+ {
+ //Find local maxima and minima event
+ g_imu_spi.compute_event();
+ //compute the euler
+ g_imu_spi.compute_euler();
+ //From the average values compute the max
+ g_imu_spi.compute_Max(buffer);
+ }
+
更新
Git cherry-pick并没有失败。我尝试按照torek的建议查看差异，发现差异确实指出樱桃选择应该包含if语句。
这是git diff --find-renames <hash-of-B> <hash-of-C>(请参考托雷克的回答(
unsigned short IMU_sendData(void)
{
@@ -2703,7 +2731,6 @@ unsigned short IMU_sendData(void)
//compute the euler
g_imu_spi.compute_euler();
//From the average values compute the max
-// g_imu_spi.compute_Max();
g_imu_spi.compute_Max(buffer);
//Low pass filter for each axis
@@ -2741,28 +2768,8 @@ unsigned short IMU_sendData(void)
}
}
git diff --find-renames <hash-of-B> <hash-of-A>已在Git Diff部分中提供。由此可见，if语句应该被挑选出来。
出错的是我选择了错误的哈希(我选择了父哈希(。
git cherry-pick通过合并来工作，但合并的输入有点不寻常。
具体来说，对于正常的、典型的合并，我们从提交图开始，从中我们找到你在分支上做了什么，以及其他人在他们的分支上做了什么：
A--B--C <-- you (HEAD)
/
...--o--o--*
D--E--F <-- them
每个圆形节点，或*或大写字母，代表一个提交(实际提交具有提交哈希ID，对于普通人来说太笨拙了(。 在这里，提交*是常见的起点，因此要让 Git 在分支上合并您的更改，Git 必须比较提交C(您的最新工作(以提交*，以查看您更改了什么：
git diff --find-renames <hash-of-*> <hash-of-C> # what you changed
同样，Git 必须比较提交F(他们的最新工作(来提交*，看看他们改变了什么：
git diff --find-renames <hash-of-*> <hash-of-F> # what they changed
Git 现在可以组合这两组更改。 如果您修改了某个文件的第 12 行，但他们没有修改，Git 会接受您的更改。 如果他们修改了同一文件的第 20 行，但您没有修改，Git 将接受他们的更改。 这两个更改都应用于提交*中显示的那个文件，以制作该文件的合并版本。
(对于真正的合并，最终，Git 会进行合并提交，它会记住两个分支提示，但对于樱桃选择，这不会发生。
Cherry-pick 使用相同的合并机制来完成 Cherry-pick，但这一次，合并基础不是什么常见的起始提交。 相反，它是您提供给git cherry-pick的名称或哈希 ID 的提交的父级：
...--o--o--o--o--A <-- master (HEAD)
o--o--B--C <-- test_imu
如果您处于这种情况，则提交A是您当前的提交，因为您在master上，并且发出以下命令：
git cherry-pick test_imu
Git 与正在提交B的合并库进行合并C的父级，这是您选择的提交 - 并提交C和A是比较的两个提交：
git diff --find-renames <hash-of-B> <hash-of-A> # what you did
git diff --find-renames <hash-of-B> <hash-of-C> # what they did
Git 现在合并了这些更改。 您会遇到合并冲突，其中你们都进行了不同的更改，但对同一文件的同一行进行了更改。
如果通过从提交B到提交A来删除if测试，但BtoC中的任何内容都不会触及if测试，Git 假定正确的操作是保留删除if测试。 但是，确定为什么Git 会像 Git 那样做的唯一方法是查看三个输入，例如，通过运行这两个git diff命令。
我发现将merge.conflictStyle设置为diff3非常有帮助，这样当发生冲突时，Git包括基本提交文件部分，以及两个相互冲突的更改。 这通常使得无需直接查看提交B。 但是，在特别复杂的情况下，您可能需要查看所有三个输入。