Git cherry-pick二三事

前天在工作中踩了个cherry-pick的坑,所以抽时间写个关于cherry-pick的用法记录下。

简介

在实际的开发工作中经常会遇到如下情况:
Git cherry-pick二三事_第1张图片

图中的abcdefgh表示不同的commmit节点, 在c节点时我们建立出了2个不同的feature branch -- feature1feature2来分别进行特性开发, 在工作中可能遇到,feature1分支开发里需要使用到commit g中所提交的内容,实现如下的效果:
Git cherry-pick二三事_第2张图片
这时候就要用到cherry-pick的功能。换言之,cherry-pick的作用就是把某个特定的 commit 内容,应用到当前分支上。

基本用法

基本命令如下:

git cherry-pick 

这里的commitId就比如上述场景里的节点g对应的commit id,可以在git log命令,或者使用gitlab页面或者其他git工具里查到。
Git cherry-pick二三事_第3张图片

进阶用法

cherry pick 同样可以pick多个commit

  • 如果是要pick独立的几个commit,可以使用如下命令:
git cherry-pick    
  • 如果是需要pick两个commit之间的所有的提交,则可以使用如下命令
git cherry-pick .. // pick m 到 n 之间的所有commit,不包括m,包括n
git cherry-pick ^.. // pick m 到 n 之间的所有commit,包含m,包括n

当然,这里的m n必须是按照时间顺序的, m必须在n之前提交。

注意事项

有必要提到的一个参数是 -n, 是--no-commit的缩写。 默认情况下git cherry-pick 命令会完成以下以下事情:

  1. 将特定commit里的改动运用到当前分支;
  2. 在当前分支上立即做一次commit,commit messagecommit 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在实际工作的基本用法和一些注意事项进行一个简单的介绍。一转眼就年底了,希望大家工作顺利,开开心心。

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


你可能感兴趣的:(git)