背景描述：有的时候基于一个master branch拉出一个独立feature分支做开发时，两条分支都在并行开发，如果master分支增加了某些功能，解决了某些关键bug，而独立feature分支不需要所有的增加的commit，只需要某一笔的修复，此时首先想到的就是单独cherry-pick该笔commit，然而后续如果再次将该feature merge回master，“奇怪”的现象发生了….

举例说明：

git仓库以ngnix代码为例，不知道什么时候clone的代码，分支还在unstable branch上。。。

• 以unstable分支为基础checkout一个test1分支。
• 在unstable分支上提交一笔commit bb3200604fcd3cefe26fb23bd6747f5563f514ac
• 在test1 branch上cherry-pick该笔commit，commit id为9b97d6038a14e348f50a7b44f2a0a29af54aa820

• 回到unstable分支，merge test1 branch，出现下面的现象：

  

为什么感到”奇怪“

• 起初我的想法时merge合并后，不会出现merge commit，也只会存在同样的一笔commit，这样看起来会很清爽，而如果出现两笔一模一样的commit，看起来会很疑惑。虽然代码没有任何问题，而且如果在提交多笔commit后再merge，大部分人都不会主要到这个现象，所以应该很少人主要到这个“问题”。
• 由于个人多少对代码有点洁癖，当发现这个现象时蛮奇怪的，为什么git不能智能记录两个branch cherry-pick的过程，在merge时只保留一个（最好是master branch上的）commit？（这点是完全可以做到的啊），不过事实就是目前的状态了。

为什么会这样？

• cherry-pick在Git中的处理应该只是将一个commit的修改重新add， commit，push到另一个branch上，并没有记录之间的关联。
• 当merge时，认为另外一个branch只是做了完全相同的修改，并没有冲突，所以完整的保留两个branch上的commit。

后续如何处理

• 虽然以上的解释很充分，原理上完全没有问题，不过对于这样的两笔一模一样的commit，感官上还是不爽的，所以我决定尽量不在需要merge回去的branch上cherry-pick父branch上的commit了。