Git cherry-pick未能选择正确的变化

clm*_*mno 1 git cherry-pick

注意:这是我身边的错误.我挑选了父哈希.请参阅本update节.
原始问题:
vmu_hw_test在分支"test_imu"中有一个文件,其变化类似于下面所示

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);
}
Run Code Online (Sandbox Code Playgroud)

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);
Run Code Online (Sandbox Code Playgroud)

问题
1.正如我所读到的,cherry-pick只需进行一次提交更改并应用它.如果分支不同(在提交历史记录中)是否有问题
2.微软文档说不要挑选.樱桃挑选是不好的做法?
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);
+                               }
+
Run Code Online (Sandbox Code Playgroud)

更新
Git樱桃选择没有失败.我尝试按照建议查看差异,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)
        }
    }
Run Code Online (Sandbox Code Playgroud)

并且git diff --find-renames <hash-of-B> <hash-of-A>已在该Git Diff部分中提供.由此我们可以看出该if陈述应该是挑选的.

出了什么问题,我选择了错误的哈希(我选择了父哈希).

tor*_*rek 5

git cherry-pick通过合并工作 - 但合并的输入有点不寻常.

具体来说,通过正常的典型合并,我们从提交图开始,从中我们发现您在分支上所做的事情,以及其他人在其分支上所做的事情:

             A--B--C   <-- you (HEAD)
            /
...--o--o--*
            \
             D--E--F   <-- them
Run Code Online (Sandbox Code Playgroud)

每个圆形节点*或大写字母表示一个提交(实际提交具有提交哈希ID,这对于普通人来说太难以处理).在这里,commit *是常见的起点,因此为了让Git 在您的分支上组合您的更改,Git必须比较提交 - C您的最新工作 - 提交*,以查看您更改的内容:

git diff --find-renames <hash-of-*> <hash-of-C>   # what you changed
Run Code Online (Sandbox Code Playgroud)

同样,Git必须比较提交 - F他们的最新工作 - 提交*,看看他们改变了什么:

git diff --find-renames <hash-of-*> <hash-of-F>   # what they changed
Run Code Online (Sandbox Code Playgroud)

Git现在可以组合这两组变化.如果您修改了某个文件的第12行,但它们没有,那么Git会对您进行更改.如果他们修改了同一个文件的第20行,但你没有修改,那么Git会对其进行修改.这两个更改都会应用于提交中显示*的那个文件,以生成该文件的合并版本.

(对于真正的合并,最终,Git进行合并提交,它会记住两个分支提示,但是对于没有发生的挑选.)

Cherry-pick使用相同的合并机制来完成一个挑选,​​但这一次,合并基础不是一些常见的启动提交.相反,它是您提供给其名称或哈希ID的提交的父级git cherry-pick:

...--o--o--o--o--A   <-- master (HEAD)
      \
       o--o--B--C   <-- test_imu
Run Code Online (Sandbox Code Playgroud)

如果您处于这种情况,A请将提交作为您当前的提交,因为您已启用master,并且您发出命令:

git cherry-pick test_imu
Run Code Online (Sandbox Code Playgroud)

Git的使得合并与合并基础是犯下B提交的-the家长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
Run Code Online (Sandbox Code Playgroud)

Git现在结合了这些变化.你得到一个合并冲突,你们两个都做了不同的更改,但是对同一个文件的同一行.

如果if测试是去除由承诺会BA,但没有在B至- C触摸if测试,Git的假设正确的动作是保持去除的的if测试.但是,确定为什么 Git做了Git所做的事情的唯一方法是查看三个输入,例如,通过运行这两个git diff命令.

我觉得这非常有助于设定merge.conflictStylediff3,所以,当有一个冲突,Git会包括基础提交的文件部分,以及两个相互矛盾的变化.这通常使得不必B直接查看提交.但是,在特别复杂的情况下,您可能希望查看所有三个输入.