前天在工作中踩了个cherry-pick的坑，所以抽时间写个对于cherry-pick的用法记录下。
简介
在理论的开发工作中常常会遇到如下状况：
图中的abcdefgh示意不同的commmit节点， 在c节点时咱们建设出了2个不同的feature branch -- feature1和feature2来别离进行个性开发， 在工作中可能遇到，feature1分支开发里须要应用到commit g中所提交的内容，实现如下的成果:
这时候就要用到cherry-pick的性能。换言之，cherry-pick的作用就是把某个特定的 commit 内容，利用到以后分支上。
根本用法
根本命令如下：
git cherry-pick <commitId>这里的commitId就比方上述场景里的节点g对应的commit id，能够在git log命令，或者应用gitlab页面或者其余git工具里查到。
进阶用法
cherry pick 同样能够pick多个commit
- 如果是要pick独立的几个
commit，能够应用如下命令：
git cherry-pick <commitId1> <commitId2> <commitId3>- 如果是须要pick两个
commit之间的所有的提交，则能够应用如下命令
git cherry-pick <commitId m>..<commitId n> // pick m 到 n 之间的所有commit，不包含m，包含ngit cherry-pick <commitId m>^..<commitId n> // pick m 到 n 之间的所有commit，蕴含m，包含n当然，这里的m n必须是依照工夫程序的， m必须在n之前提交。
注意事项
有必要提到的一个参数是 -n， 是--no-commit的缩写。 默认状况下git cherry-pick <commitId>命令会实现以下以下事件：
- 将特定
commit里的改变使用到以后分支； - 在以后分支上立刻做一次
commit,commit message即commit id对应的那次commit。
第一点没有疑难，然而第二点这个性能如果不留神（尤其是习惯应用小乌龟，source tree之类的敌人）进行cherry-pick时，如果没认真看的话，在某些场景下很容易出问题，举个例子：
对于某些项目组，我的项目的开发周期划分比拟清晰，代码的提交阶段分为个别开发阶段，回归测试fix阶段等等，这种划分会体现在commit message的前缀里,假如规定如下：
- 开发阶段的所有
commit message必须是DEV:xxxxx的模式，xxx是具体的提交内容； - 回归测试阶段，所有
commit message必须RT:xxx模式，xxx是具体的提交内容；
（这类规定在大型项目里比拟常见，能够比拟不便地做一些治理和统计，比方防止在回归阶段做新性能开发等等），接下来就是重点了:
如果咱们在回归测试阶段遇到一个bug须要fix，并且在fix过程发现有一些改变时能够借用其余分支在开发阶段某次commit的内容。这时候很天然地，咱们会想到应用cherry-pick，然而这时候如果不应用 -n参数，就会导致把开发阶段的commit message，提交到RT阶段。（前事不忘;后事之师，心愿大家不要像我一样犯这种谬误-_-） 所以十分倡议每次应用 cherry-pick都带上-n参数，即只保留文件改变,不做额定commit
小结
本文针对cherry-pick在理论工作的根本用法和一些注意事项进行一个简略的介绍。一转眼就年底了，心愿大家工作顺利，开开心心。
常规：如果内容有谬误的中央欢送指出（感觉看着不了解不难受想吐槽也齐全没问题）；如果有帮忙，欢送点赞和珍藏，转载请征得批准后著明出处，如果有问题也欢送私信交换，主页有邮箱地址