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在实际工做的基本用法和一些注意事项进行一个简单的介绍。一转眼就年末了，但愿你们工做顺利，开开心心。

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