背景：
早上发生一件很诡异的事情。昨晚上线的0-2分支代码并非该分支最新代码。git master上代码也非最新。但通过git页面查看0-2分支，代码确实是最新状态。
在0-2分支上线前，由于其他分支有上线操作，于是通过公司基于tag模式的合并代码方式手工合并过一次代码，打了个tag 后继续0-2分支的开发。问题就出在这个tag上。由于git上线操作
先来查看一下git操作记录流程
在“1、”中，完成了上述合并代码打tag的操作。“3、”为继续修改0-2分支后的最新代码。而上线时，是将，“1、”的tag上线的到了“2、”matser上。而理论上应从走向应从“3、”到“2、”才能保证上线的代码为0-2上最新的。
寻找症结
原因在于上线前，0-2分支的tag操作。tag就形同一个里程碑，在执行上线代码时，可由两种思路，一个是根据每次的commit，获取最新的commit进行上线。另一个就是以tag为标记，上线则通过最新tag的代码进行上线。而上图中修改后的代码并未打tag，导致上线获取最新的tag即为“1、”中代码，“1、”到“3、”的代码修改则未上线。
解决方案
而后，新拉一个分支0-4，复制0-2的上最后一个commit的id，执行cherry-pick操作。
cherry-pick 会重演某些commit操作, 即把某些commit的更改重新执行一遍。于是进入到0-4分支，执行如下命令即可将0-2上对应的commit代码执行在0-4分支。
git cherry-pick
20c2f506d789bb9f041050dc2c1e954fa3fb6910
21d41fba035db15717e07385caf1f46edf1deb52
最后上线0-4即可。