科学使用cherry-pick

无意中发现一篇文章不要再使用cherry-pick啦。看完之后，发现还是cherry-pick真香，个人看法如下：

一般使用cherry-pick是在提交代码前发现代码落后时，整理个人开发分支代码，此时解决发现的冲突确实对后续的开发埋下雷，但这种情况特别少见。

像以小组合作开发的团队，其实这种情况很容易处理，开发小组组件涉及人员少，日常交流多。怎么合理的解决这部分冲突大家很容易达成共鸣；还可以使用下面这种更专业的方式。

开源代码的维护和开发一般涉及到很多线上开发者的情况，此时没有办法开会或者沟通所有相关人员。遇到这种情况，读过程序员的自我修养的开发者一般也不会轻易解决冲突就提合并请求，而是会针对冲突部分代码影响到的内容做审查，如果非要解决冲突才可以，就针对性单独提交一个相当于合并的节点；而不是将解决冲突藏在另一个开发节点中。