共计 1529 个字符，预计需要花费 4 分钟才能阅读完成。
前天在工作中踩了个 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，包含 n
git 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 在理论工作的根本用法和一些注意事项进行一个简略的介绍。一转眼就年底了，心愿大家工作顺利，开开心心。
常规：如果内容有谬误的中央欢送指出（感觉看着不了解不难受想吐槽也齐全没问题）；如果有帮忙，欢送点赞和珍藏，转载请征得批准后著明出处，如果有问题也欢送私信交换，主页有邮箱地址