Git cherry-pick二三事

前天在工作中踩了个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>命令会完成以下以下事情：

1. 将特定commit里的改动运用到当前分支；
2. 在当前分支上立即做一次commit,commit message即commit id对应的那次commit。

第一点没有疑问，但是第二点这个功能如果不注意（尤其是习惯使用小乌龟，source tree之类的朋友）进行cherry-pick时，如果没仔细看的话，在某些场景下很容易出问题，举个例子：

对于某些项目组，项目的开发周期划分比较清晰，代码的提交阶段分为一般开发阶段，回归测试fix阶段等等，这种划分会体现在commit message的前缀里,假设规则如下：

1. 开发阶段的所有commit message必须是DEV:xxxxx的形式，xxx是具体的提交内容；
2. 回归测试阶段，所有commit message必须RT:xxx形式，xxx是具体的提交内容；

（这类规则在大型项目里比较常见，可以比较方便地做一些管理和统计，比如避免在回归阶段做新功能开发等等），接下来就是重点了:

如果我们在回归测试阶段遇到一个bug需要fix，并且在fix过程发现有一些改动时可以借用其他分支在开发阶段某次commit的内容。这时候很自然地，我们会想到使用cherry-pick，但是这时候如果不使用 -n参数，就会导致把开发阶段的commit message，提交到RT阶段。（前车之鉴，希望大家不要像我一样犯这种错误-_-） 所以非常建议每次使用 cherry-pick都带上-n参数，即只保留文件改动,不做额外commit

小结

本文针对cherry-pick在实际工作的基本用法和一些注意事项进行一个简单的介绍。一转眼就年底了，希望大家工作顺利，开开心心。

惯例：如果内容有错误的地方欢迎指出（觉得看着不理解不舒服想吐槽也完全没问题）；如果有帮助，欢迎点赞和收藏，转载请征得同意后著明出处，如果有问题也欢迎私信交流，主页有邮箱地址

---