注意:这是我的错误。我挑选了父哈希。请参阅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 document说不要挑剔。采摘樱桃不好吗?
3.为什么采摘樱桃会失败? (更新:没有。)
Git Diff
对于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>
(请参阅torek的答案)
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
语句应该被挑选。
出问题的是,我选择了错误的哈希(我选择了父哈希)。
答案 0 :(得分:5)
git cherry-pick
通过合并工作,但是合并的输入有点不寻常。
具体来说,通过正常的典型合并,我们从提交图开始,从中我们可以找到您在分支机构上所做的与其他人在其分支机构上所做的:>
A--B--C <-- you (HEAD)
/
...--o--o--*
\
D--E--F <-- them
每个回合节点(或*
或大写字母)表示一次提交(实际的提交具有提交哈希ID,对于普通人来说,它们太笨拙了,无法使用)。在这里,提交*
是常见的出发点,因此,为了使Git结合分支上的您的更改,Git必须比较提交C
(您的最新工作)来提交{{ 1}},看看您所做的更改:
*
同样,Git必须比较提交git diff --find-renames <hash-of-*> <hash-of-C> # what you changed
(它们的最新工作)来提交F
,以查看它们的变化:
*
Git现在可以组合这两组更改。如果您修改了某个文件的第12行,但没有修改,则Git会进行更改。如果他们修改了同一文件的第20行,但您没有修改,则Git接受他们的更改。这两种更改都将应用于提交git diff --find-renames <hash-of-*> <hash-of-F> # what they changed
中的一个文件,以合并该文件。
(对于真正的合并,最终,Git会进行 merge commit ,该操作会记住两个分支提示,但不会发生樱桃挑剔。)
Cherry-pick使用相同的合并机制来完成Cherry-pick,但是这次 merge base 并不是一些常见的起始提交。相反,它是提交给*
的名称或哈希ID的提交的 parent :
git cherry-pick
如果您处于这种情况下,由于您在...--o--o--o--o--A <-- master (HEAD)
\
o--o--B--C <-- test_imu
上,因此提交A
是当前的提交,并且您发出以下命令:
master
Git进行合并,合并基础为提交git cherry-pick test_imu
(提交B
(即您正在选择的提交)的父对象)并提交{{1} }和C
是得到比较的两个提交:
C
Git现在结合了这些更改。您会遇到合并冲突,在这两者中您进行了不同的更改,但是对同一文件的同一行进行了
。如果通过提交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
删除了if
测试,但是从B
到{{ 1}}触摸A
测试,Git假定正确的操作是保持删除B
测试。但是,唯一确定为什么 Git所做的事情的唯一方法是查看这三个输入,例如通过运行这两个C
命令。
我发现将if
设置为if
非常有帮助,这样,当发生冲突时,Git包括了基本提交文件部分以及两个矛盾的变化。这通常使得不必直接查看提交git diff
。但是,在特别复杂的情况下,您可能需要查看所有三个输入。