企业官网建设流程全解析

1. 为什么你需要 cherry-pick：这功能到底解决什么问题

先说结论：cherry-pick 是我在 SourceTree 里用得最频繁但也是最容易被人忽略的功能，甚至有些用 Git 好几年的人都没点开过它。它的核心作用就是一句大白话——“从别的分支里挑一两个提交，弄到当前分支来”。

听起来很简单对吧？但在实际项目里，这个操作的价值几乎每天都能体现。我举个例子：你在 dev 分支上开发了三天的功能，测到一半发现生产环境的某个紧急 bug 必须马上修，而这个 bug 的修复代码恰好也躺在 dev 分支里——可 dev 上还带着一堆没测完的实验性改动，这时候你总不能把整个 dev 直接合到 master 上。正确的办法就是把那一条修复提交单独“摘”出来，放进 master。这个“摘”的动作，就是 cherry-pick。

还有一个高频场景：你在不同版本的维护分支上干活，比如 v1.0 分支和 v2.0 分支同时维护，v1.0 修了一个严重的内存问题，v2.0 也需要同步这个修复，但两条分支的演进路线早就分道扬镳，直接 merge 会把一堆不该来的东西也带过来。这种场景下，cherry-pick 几乎是唯一合理的解法。

所以说，它适合谁？适合所有在用 Git 做项目的人，尤其是那些经常要处理多分支、版本发布、线上热修的开发者和运维。今天这篇就专门讲 SourceTree 里的 cherry-pick，从界面操作到冲突处理，从原理到避坑，争取让你看完就能直接上手。

2. 动手之前的准备：先把工作区搞干净

很多人在 SourceTree 里点 cherry-pick 失败，问题根本不在操作本身，而是动手之前没把仓库状态整理好。这个环节我建议你养成习惯，能省掉后面一堆莫名其妙的错。

2.1 检查工作区是否干净

在 SourceTree 右上角有一个“提交”按钮，旁边的小数字提示当前有多少个未提交的改动。如果这个数字不是 0，cherry-pick 时 SourceTree 会警告你，严重的情况下会直接中断操作。

原因很容易理解：cherry-pick 本质上是在当前分支上生成一次新的提交，它要把这次的变更应用到你当前的文件状态上。如果工作区里还有没提交的改动，两边文件一冲突，就可能把未提交的改动和遴选过来的改动搅在一起，到时候你想回退都分不清谁是谁。

所以我在实操前的标准动作是：要么先把改动提交掉，要么先暂存（Stash）。SourceTree 里有个“暂存”按钮，点了之后能把工作区的改动收起来，等 cherry-pick 完成后再“暂存弹出”恢复回来。尤其是那种只改了一半、还不想提交的代码，一定要用这个功能护住。

2.2 切换到正确的目标分支

这条看起来是废话，但坑踩多了你就知道，好多人就是在这种细节上翻车的。cherry-pick 的方向是“把其他分支的提交应用到当前所在分支”，所以你先要确认自己当前在哪个分支上。

在 SourceTree 左侧的分支栏里，当前分支会加粗，而且主界面的顶部会有分支名显示。我的习惯是双击目标分支做一次切换，然后看一眼提交列表，确认现在的 HEAD 指向对了再继续操作。这一眼花不了三秒钟，但能避免你把修复弄到开发分支上、又在生产分支上空等半天的尴尬。

2.3 定位你要“摘”的提交

这一步需要一点耐心。SourceTree 的提交列表默认显示当前分支的历史，但你要摘的提交很可能不在当前分支上。这时候你可以直接在主界面上方找到分支下拉框，切换到源分支查看它上面的提交记录。

我通常会结合 SourceTree 顶部的搜索框来定位，输入提交信息里的关键词，比如跟 bug 修复相关的工单号或者业务名，能很快过滤出来。定位到目标提交之后，先右键点一下，看看菜单里是不是有“遴选...”这个选项——这里要注意，SourceTree 的中文版本里 cherry-pick 被翻译成了“遴选”，第一次用的人可能会找不到，很多人就是在右键菜单里看到一堆英文术语直接懵了。

3. 正式操作：SourceTree 里如何执行 cherry-pick

铺垫了那么多，现在进入正题。我把操作拆成两种情况：摘一条提交，和摘连续的多条提交。两种情况我都实际用过，流程不太一样，建议你仔细看完。

3.1 摘一条提交：最快的方式

定位到目标提交后，右键单击，选择“遴选”（有的版本显示为“Cherry Pick...”），SourceTree 会弹出一个窗口。

这里要注意，弹出的窗口里有几个选项需要你理解清楚，不能无脑点确定：

• “提交”按钮：这是执行遴选的主按钮，点击后才会真正生成新提交。
• “提交并推送”按钮：提交后立刻推送，适合你确定要推远程的场景。
• 中间的选区或者输入框：让你确认要遴选的分支和提交信息，一般不需要手动改。

我个人的习惯是：本地先点“提交”，看一眼 SourceTree 右侧显示的提交记录和变更内容，确认没有问题之后，再手动推送。不要没事就点“提交并推送”，万一选错了提交，你还能在本地回退；一旦推上去了，就得走 revert 或者强制推送，麻烦程度翻倍。

执行成功后，SourceTree 会提示操作完成，当前分支的提交历史里会新增一条提交，提交内容和源提交完全一致，但提交的 SHA 值已经变了，作者信息默认保留原作者的。这里容易产生一个混淆点，后面我在常见问题里专门讲。

3.2 摘连续的多条提交：用拖拽更高效

有时候你要的不是一条，而是从某个提交开始往后的连续几条。最常见的场景是：你在功能分支上按“小步提交”的方式写了五六个 commit，现在要把这个功能整体搬到另一个分支上。

SourceTree 针对这种场景有一个比较好用的操作方式：先选中最早的提交，然后按住 Shift 键，再选中最后一个提交，这样就能框选一段连续的提交记录。选中之后，直接用鼠标左键按住这组提交，拖拽到左侧分支栏里的目标分支上，松手之后 SourceTree 就会自动对这整段提交执行遴选。

这个小技巧第一次用的时候会觉得很爽，因为它省掉了“逐个右键、逐个确认”的重复劳动。但要注意：拖拽执行时 SourceTree 不会弹窗让你一个个确认，而是按顺序依次应用。如果中间某一个提交遇到冲突，操作会自动停下来，把工作区调整为冲突状态，让你处理完再继续。

这里有个非常重要的注意点：拖拽多段提交时，各个提交是“按顺序逐个应用”的，假如第一个提交里改了 A 文件的第三行，第二个提交里又改了 A 文件的第五行，如果目标分支上 A 文件已经很不一样了，那第一个提交就可能和现状冲突，第二个提交又会和第一个提交生成后的状态冲突——总之，多段遴选本质上就是在做连环合并，冲突概率比单条高得多。我的建议是，能少摘就少摘，千万别为了偷懒把一大段都拖过去。

3.3 冲突出现时：SourceTree 的处理流程

无论单条还是多条，只要代码有差异，就一定会遇到冲突。这部分是整个 cherry-pick 流程里最有技术含量的环节，新手往往在这里卡壳，所以我单独拿一个章节来讲。

当冲突发生时，SourceTree 主界面的文件列表里，有冲突的文件会同时出现在“已暂存文件”和“未暂存文件”区域，文件名旁边会有一个黄色的感叹号标记，这就是冲突文件的标准状态。

接下来你的处理路径一般是这样：

第一步，双击冲突文件，SourceTree 会弹出外部合并工具。如果你没配置过，它会提示你先设置合并工具。我这里多说一句，比较推荐的组合是 VS Code 作为编辑器，Beyond Compare 或者 Meld 作为专门的对比合并工具。如果你只装了编辑器，也可以直接选“不打开外部合并工具”，用编辑器手动查看文件内容。

第二步，在合并工具里，通常会给你展示三个面板：左侧是本地版本（目标分支的代码），右侧是“他们”的版本（要遴选过来的代码），中间是合并面板，里面会有类似这样的冲突标记：

<<<<<<< HEAD 本地当前分支的代码 ======= 从其他分支遴选过来的代码 >>>>>>> 源提交的标识

你要做的，就是把<<<<<<<、=======、>>>>>>>这些标记删除，保留你真正想要的代码片段。要么选择本地的，要么选择对方的，要么手动拼出两者结合后的代码。这一步没有任何自动化捷径，你只能靠对业务的熟悉程度来决定。

第三步，处理完文件之后，回到 SourceTree 主界面，找到这个文件，点击文件前面的“已暂存”状态切换按钮，把它标记为“已解决冲突”。SourceTree 里的操作逻辑是：冲突文件必须被重新“暂存”（Stage）之后，界面右上角才会出现“提交”按钮，并提示“解决冲突后提交遴选”。这个设计是刻意的，就是为了防止你还没处理干净就稀里糊涂提交了。

最后，点击“提交”按钮提交这一次遴选。到此，冲突处理流程就算走完了。

4. 常见问题与排查技巧实录

这一节我专门整理了自己和其他开发者交流时高频碰到的问题。很多问题本身就带着误导性，光看报错信息根本猜不到原因。

4.1 提示“无法遴选：提交已存在于当前分支”

这个提示出现过好几次，我一开始也没反应过来。它的意思并不是你操作错了，而是 Git 认为你要摘的那个提交内容已经在当前分支里了。

最典型的原因是：你曾经用 merge 把另一个分支合进来过，而 merge 往往会把这个分支上的提交带过来，Git 比对对象 ID 后自然就判断“这个提交已经存在”。还有一种情况是，之前已经执行过一次相同的 cherry-pick，产生的新提交虽然 SHA 值变了，但提交补丁的内容哈希和之前一样，Git 对比后认为内容重复。

解决办法很简单：要么换一个提交来摘，要么用--force之类的参数强制执行——但 SourceTree 的界面里并不直接暴露这个选项，所以我建议你在命令行里敲：

git cherry-pick -m 1 提交SHA --allow-empty

这里多提醒一句，真的遇到了这种提示，先停下来想一下“这个提交是不是已经进来了”，别盲目强制。强制操作有可能会把同一份修改重复应用，完事之后代码里出现两段完全相同的改动，排查起来非常痛苦。

4.2 冲突解决后 SourceTree 不让你提交

这个也是新手高频问题。冲突文件在 SourceTree 里会比普通文件多一个“已暂存”和“未暂存”的切换逻辑。处理完冲突之后，很多人直接点右上角的提交按钮，发现按钮是灰的，或者提示“没有可提交的变更”。

我上面说过，源文件里的冲突标记处理干净还不够，你还得把文件“重新加入暂存区”。在 SourceTree 的文件列表里，冲突文件会同时出现在上下两个区，你要在“未暂存文件”区域找到那个文件，点击它前面的加号图标，把它加入暂存区，这样右上角的提交按钮才会激活。

这个操作在底层对应的就是git add，但很多人习惯用 SourceTree 之后早忘了底层命令，遇到这种状态切换就卡住。多花三十秒理解一下“暂存区”的概念，这类问题就能迎刃而解。

4.3 关于提交作者信息和 SHA 值的问题

我之前有个同事很疑惑：cherry-pick 成功之后，为什么提交卡片上的作者名字还是原来那个作者，而不是他？他以为既然是从他操作的，提交人应该是他才对。

这个认知需要纠正一下：Git 里的提交人（Author）和提交者（Committer）是两个字段。cherry-pick 默认会把原始提交的作者信息保留下来，表示“这个改动的原创者是谁”，但同时会把提交者设成当前执行操作的人。在 SourceTree 的提交详情面板里，你可以同时看到 Author 和 Committer 两个字段，平时如果不展开查看可能不太注意。

另外，每次 cherry-pick 都会生成一个全新的 SHA 值。哪怕内容一模一样，SHA 也不一样，因为提交的父节点、提交时间等信息已经变了。这个特性导致的结果是：你不要试图用 SHA 值去判断“这个提交是不是那个提交”，用内容去判断更靠谱。

4.4 连续遴选到一半冲突，操作停在半路怎么办

这种情况我遇到过好多次。你拖了一段提交过去，第一个冲突解决了，点了提交，结果第二个提交又冒出来冲突。这时候系统会继续停在这个环节，直到你把当前这个冲突处理完，才能真正继续后续的遴选。

有些人在这个阶段会选择放弃，直接在 SourceTree 里点“中止”按钮。这里我先说清楚：SourceTree 的中止操作，会把你之前已经处理完并提交的那部分遴选提交都回滚掉，整个 cherry-pick 操作撤销，回到一开始的干净状态。所以不要随便点中止，除非你确定之前的提交都不要了。

如果你只是想暂停一下、而不是完全撤销，那么处理完当前冲突后，可以继续提交。但如果你已经开始解决了一个文件、还没做完，就直接关掉 SourceTree，再打开时 Status 会依然停留在冲突状态。别慌，继续处理就行了，Git 的合并状态是持久化的，不会因为你关了软件就消失。

下面用一个速查表把常见问题整理出来，方便你以后直接对照：

4.5 几个我踩过的坑，提前帮你避开

第一个坑：在 SourceTree 里选择“提交并推送”时手滑选成了“提交到另一个分支的远端”。这是真实发生过的事，我同事一次把功能分支的提交直接推到了 master 远端，后来用了 revert 才把线上恢复。所以我强烈建议，推送这一步永远单独做，而且推送前认真看一眼目标仓库和目标分支的选项。

第二个坑：选提交时看到的“最新提交”是远端分支的，不是本地的。SourceTree 左侧会同时展示本地分支和远程分支节点，很多人没刷新就看了远程分支上的提交，以为那是自己本地的，结果遴选之后发现本地分支根本没有那个提交。

第三个坑：处理冲突时用编辑器直接删标记，但保存时不小心保留了 BOM 或者多余空格。这种问题不会报错，但代码风格和 diff 会变得很难看。处理完冲突后，我建议顺手跑一遍代码格式化工具，把可能引入的多余空白统一清理掉。

5. 命令行对照：看懂 SourceTree 背后到底执行了什么

我知道这篇文章是讲 SourceTree 的，但如果你完全不了解背后对应的 Git 命令，一旦遇到界面操作搞不定的情况，想哭都找不到地方哭。所以我单独把命令行对照写出来，你可以一边看 SourceTree 界面，一边在 Git Bash 里敲命令，两个一对应，理解立刻就会上一个台阶。

5.1 单个动作的底层命令

你在 SourceTree 里右键选择“遴选”，实际上 SourceTree 在后台执行的就是：

git cherry-pick 提交SHA

这个命令最简单的形式就是这一句。它会把指定的提交应用到当前分支，并产生一次新的提交。如果你在界面上勾选了“不立即提交”之类的选项，那对应的就是：

git cherry-pick -n 提交SHA

-n的含义是只把改动应用到工作区和暂存区，但不生成新的提交，相当于“先把内容拿过来，怎么提交我自己之后再定”。

当你遇到冲突的时候，Git 会把冲突文件的标记写入文件里，然后你在 SourceTree 界面解决完冲突、点“提交”的时候，后台是在执行：

git add 冲突文件 git cherry-pick --continue

这里有个冷知识：一旦进入冲突状态，Git 是很倔强的，你没法正常做其他操作。处理完冲突之后如果不执行git cherry-pick --continue，Git 会一直卡在那个“遴选进行中”的状态，导致你切换分支都会被拒绝。SourceTree 界面上你可能看不出这个状态，但在 Git Bash 里能直接看到：

You are currently cherry-picking commit 3f6a2b1c.

所以如果真的在界面上迷失了，打开命令行，输入git status，它会用很直白的文字告诉你现在处于什么状态，下一步应该怎么走。

5.2 批量操作的底层逻辑

拖拽连续提交这组操作，在底层其实相当于是：

git cherry-pick 第一个提交SHA^..最后一个提交SHA

这个语法表示“把从第一个提交到最后一个提交之间的所有提交都选过来”。注意，我写了第一个提交SHA^，这个^符号表示第一个提交的父提交，原因是区间范围A..B在 Git 里通常不包含左端点 A 本身，加上^才能把 A 也包括进去。

如果你发现拖拽操作的应用顺序和你预期的不一样，可以试试手动指定顺序。SourceTree 的批量遴选是按时间从旧到新逐个应用的，这也是默认的合理顺序。要是你在界面上想把顺序反过来，那就没法直接拖了，只能一条一条地遴选，先摘最晚的那条，再依次往前摘。

5.3 一些命令行下很有用的扩展场景

有些操作在 SourceTree 里做不了，但在命令行里能做。比如，你可以指定把源提交的提交信息重新编辑再生成新提交：

git cherry-pick 提交SHA git commit --amend

还有更精细的：只要代码变更，不要提交历史：

git cherry-pick -n 提交SHA git checkout -- . # 撤销暂存但保留工作区改动，视情况使用

如果你的项目需要多个分支同步同一个修复，写一个循环脚本是最高效的方式：

for branch in release/v1.0 release/v1.1; do git checkout $branch git cherry-pick 3f6a2b1c git push origin $branch done

这种脚本我以前在维护一个老项目时经常跑，几条分支一次性同步修复，比在 SourceTree 里手工切换五六次快得多。当然，跑之前一定要确认每个分支的工作区是干净的，不然 checkout 那一步就直接报错了。

6. 一套实用的工作流建议

最后把我个人的一套工作流分享出来，不一定适合所有人，但至少是我踩了无数次坑之后沉淀下来的。这套流程的核心就一句话：把 cherry-pick 当成“合并手术”来对待，而不是随手一点就完事的小操作。

第一步，永远先更新目标分支。在 SourceTree 里选中目标分支，双击切换过去，然后拉取一次，确保本地是最新的。

第二步，在源分支上定位提交。不要凭记忆找，用搜索框定位，核对三样东西：提交信息、改动的文件列表、改动的内容摘要。SourceTree 右侧会显示每个提交的详细差异，我建议至少扫一眼改动量，心里有数。

第三步，执行遴选时，先选择“只提交到本地”，不要选“提交并推送”。提交成功之后，再在提交列表里确认一次新生成的提交，检查作者、提交信息、改动内容，然后手动点推送。

第四步，如果遇到冲突，按我说的流程处理：外部分析工具打开，看清冲突标记，解决一个就暂存一个，最后统一提交。千万不要在处理到一半的时候去点 SourceTree 里的“中止”，那等于前功尽弃。

第五步，推送之后，在远程仓库页面（GitLab、GitHub、Gitee 等都行）再核对一次提交记录，确保推送成功且没有把杂七杂八的提交一起带上去。

讲到这里，SourceTree 的 cherry-pick 遴选功能基本上已经被我拆得很透了。实际操作中你会发现，这个功能用熟练之后，多分支开发和非并行项目管理的效率会有很明显的提升。如果你正在维护的项目里经常需要把某个修复从一条分支搬到另一条分支，花一个下午把这篇内容从头到尾跟着操作一遍，之后就不会再被这类问题卡住了。