前提条件：有2个分支，分别是master，hotfix，其中master是用于生产环境的发布分支。
场景1：生产环境hotfix。
T1时刻，使用master分支发布生产。当时的HEAD的commit记为C1.
T2时刻，开发完成下一个迭代周期的代码，并且merge到master准备提测，此时master的HEAD记为C2，注意：C1和C2已经不同了。
T3时刻，生产环境发现了bug，开发基于C1创建一个hotfix分支，代码紧急修复并签入hotfix，用C3表示这个commit，发布生产。
问题：由于hotfix不能基于C2创建（T2时master已污染，存在下一周期待提测代码），如何确保C3被正确merge到master呢？
答案：使用git cherry-pick命令。
git checkout dev // 每个开发人员有自己的dev分支，这个分支基于master创建，时刻和master同步
git cherry-pick -n C3 //C3是hotfix的提交sha-1
git commit -am "把hotfix(C3)的代码cherry-pick到master"
git push origin dev
最后，去gitlab里发起一个MergeRequest吧，dev->master。
场景2：某一个产品有3个分支，master，feture1，feture2。其中，
master是基础功能，覆盖全体用户；
feature1包括中级功能，覆盖一部分用户；
feature2包括高级功能，覆盖另一部分用户；
由于业务领域的特征，这3个分支一直并行存在，feature1和feature2永远不会回归主线master。
T1时刻，feature1新增了5个功能（commit），分别记录为F1、F2、F3、F4，F5; 假定这5个commit是顺序提交的。
T2时刻，决定把F1、F2、F3的这3个功能开放给所有用户。
问题：如何在feature1分支中挑选需要的功能，并最终合并到master呢？
答案：使用git cherry-pick命令。
git checkout dev // 每个开发人员有自己的dev分支，这个分支基于master创建，时刻和master同步
方法1：git cherry-pick -n (F1^..F3] // 注意：这是一个左开右闭区间，因此第1个参数要设置成F1^（F1的上一次提交），这样才能把F1也包含进去。
方法2：依次执行3条命令，
git cherry-pick -n F1
git cherry-pick -n F2
git cherry-pick -n F3
git commit -am "F1、F2\、F3的代码cherry-pick到master"
git push origin dev
最后，去gitlab里发起一个MergeRequest吧，dev->master。
原文：https://www.cnblogs.com/auv2009/p/12801188.html