Git Cherry-pick，通常叫做摘樱桃。此为Git 的一种操作，作用是将部分代码从一个分支转移到另一个分支。
一般情况下，我们采用的是 git merge的方式来合并两个分支的代码。这种情况，适用于我们需要另一个分支的所有代码变动（包含创建分支前的base代码）。
另一种情况是，你只需要部分代码变动（某几个提交），那么就可以采用 Cherry pick。
下面通过一个实例讲解下操作步骤：
分别有A、B两个开发团队做同一个项目，开发侧接到一个版本需求，假定需要在2021.01.21上线，A做财务相关功能，B做服务相关功能。
A团队由于时间充裕，提前进入开发，在1月8号从dev新建了一个分支，取名： dev-finance-20210121。
一顿操作，1月12号，A团队开发好了，于是通过merge方式将 dev-finance-20210121 分支合并到dev分支。
1月13号，此时B团队忙完了手头的事，进入开发阶段，于是从dev新建另外一个分支，取名： dev-service-20210121。注意：此时创建的分支包含了A团队提交的内容。
1月15号，B团队也开发好了，于是通过merge方式将 dev-service-20210121 分支合并到dev分支。
两边开发完毕，只等测试对不对。
但是，突然1月16号，A团队由于依赖方延期原因，上不了线了，产品也同意，需要回退！而B团队的功能正常上线。
那么，就得把dev的代码整体回退到未开发之前的版本。duang duang duang，回退成功！
此时，dev分支上，缺少了A团队提交的代码，没问题。可是缺少了B团队提交的代码，这怎么能行呢，B还得上线吖。
再次通过merge方式将 dev-service-20210121 分支合并到dev分支？
额，不行， dev-service-20210121分支创建于A团队提交之后，包含了A提交的代码，这样会把A团队提交的内容整体带过去。
假如重新建分支，再把之前的改动，一段一段代码拷贝进去，这样更不行，太麻烦了，而且容易漏。
怎么办呢？嘿嘿，这时咱们的 Cherry pick 就起作用了。
直接将 dev-service-20210121 分支 Cherry pick 到 dev分支虽然可以实现，但是测试阶段，开发还得改啊。难道每次改了都 Cherry pick 吗？这多麻烦。
此时，采用新建分支+ Cherry pick的方法，之后就可以使用merge方式了。
于是，1月17号，B团队再次从dev新建一个分支，取名： dev-service-20210121-new。注意：此时创建的分支不包含A团队提交的内容，因为dev分支已经回退了。
采用 Cherry pick 方式，B团队将 dev-service-20210121 分支上提交的部分合并到 dev-service-20210121-new 分支。
再把 dev-service-20210121-new 分支 merge 到 dev分支。这时，就实现了dev分支上，只包含B团队提交的内容。
废弃dev-service-20210121分支，之后B团队就在 dev-service-20210121-new 分支上修改bug，修改完bug，合到 dev 分支时，想怎么merge怎么merge。
怎么操作呢？请看下面在idea中的示例：
1.右键module名称，将项目切换到新的分支 dev-service-20210121-new
2.打开git Log，找到该module的git Log窗口，选择select，查询原来的 dev-service-20210121分支
3.从提交历史中，选中需要合并过来的提交内容，右键进行 Cherry pick。（如果有冲突，说明你切换到新分支后，在本地改过代码又没有提交，这时需要解决冲突）
4.这样就把 原来的 dev-service-20210121分支需要的提交内容合并到本地啦。当然这个只是在本地，如果要合并到 新分支 dev-service-20210121-new，还需要右键 module ，push一下（Cherry pick 到本地的代码部分是默认提交的，无需commit了）。
5、这样就大功告成啦，之后可以任意从 dev-service-20210121-new 新分支merge到 dev分支了（不带A团队提交的内容）。如测试阶段有bug ,要改代码也在 dev-service-20210121-new 上改。
至此，通过 Git Cherry-Pick(摘樱桃) 方式实现了只上线部分功能的需求。