type
status
date
slug
summary
tags
category
icon
password
一、Cherry-Pick 的核心概念与使用场景
1. 什么是 Cherry-Pick？
git cherry-pick 是 Git 中一项选择性合并提交的功能，允许开发者将特定提交从一个分支复制到另一个分支，而无需合并整个分支的历史记录。其核心特点包括：- 精准移植代码：例如将修复 Bug 的提交单独应用到生产环境（如
master）或预发布分支（如release）
- 生成新提交：原提交的哈希值会改变，但代码内容保持一致
- 支持多提交操作：可一次性选择单个或多个提交（如
git cherry-pick A..B或A^..B），需注意提交顺序
- 冲突需手动解决：若目标分支存在冲突，需手动编辑后继续操作
2. Cherry-Pick 的典型场景
- 紧急修复：将
hotfix分支的修复提交快速移植到release分支。
- 多分支协作：在并行开发中，将某个功能的提交跨分支共享。
- 代码回溯：恢复误删的功能提交到其他分支。
二、Merge 代码到 Master 或 Release 的策略
1. 合并到 Master（生产环境）
- 直接合并：适用于稳定功能的整体合并（如
git merge feature），但需通过完整测试
- Cherry-Pick（推荐）：仅挑选已验证的提交，避免污染生产环境代码。例如将
feature分支的commitB单独应用到master：
Bash
git checkout master git cherry-pick commitB2. 合并到 Release（预发布环境）
- 传统流程：从
dev分支合并到release，适用于全量测试：
Bash
git checkout release git merge dev- 敏捷流程：通过 Cherry-Pick 将特定功能提交从
feature分支直接应用到release，适合多版本并行开发
三、互联网公司的完整代码合并流程
1. 分支策略与开发规范
互联网公司通常采用以下分支模型之一：
- Git Flow：包含
master（生产）、develop（开发）、feature（功能）、release（预发布）、hotfix（紧急修复）分支，适合多版本维护
- GitHub Flow：仅保留
master分支，所有功能通过 Pull Request（PR）合并，适合持续交付
- GitLab Flow：结合环境分支（如
staging、production），强调 CI/CD 集成
2. 典型开发与合并流程
- 需求开发阶段：
- 从
master或develop拉取feature分支进行开发。 - 提交代码至远程仓库，触发自动化构建与单元测试
- 联调与测试阶段：
- 将
feature分支合并到dev分支进行集成测试。 - 测试通过后，通过 Cherry-Pick 或 Merge 将代码同步到
release分支进行预发布验证
- 发布与生产阶段：
release分支通过验收后，合并到master分支并打 Tag 标记版本。- 若线上出现 Bug，从
master拉取hotfix分支修复，验证后合并回master和develop58。
3. 代码审查与冲突解决
- PR/MR 机制：通过 GitLab 或 GitHub 的 Merge Request 流程，要求至少两人审查代码
- 冲突处理：若合并时出现冲突，需在本地解决后重新提交或使用
git cherry-pick --continue继续操作
四、流程对比与最佳实践
1. 合并工具对比
操作 | Cherry-Pick | Merge |
适用场景 | 选择性移植提交（如紧急修复） | 整体合并分支（如功能全量发布） |
提交历史 | 生成新提交，原记录保留 | 保留原提交，生成合并节点 |
冲突频率 | 较高（需手动处理依赖） | 中等（需解决整体差异） |
2. 最佳实践
- 分支规范：明确分支生命周期（如
release分支在发布后删除）
- 代码审查：强制要求 PR 审查，结合自动化工具（如 SonarQube）检查代码质量
- 版本标记：使用语义化版本号（如
v1.2.3）并关联 Tag，便于回滚与追踪
- 自动化流水线：集成 CI/CD 工具（如 Jenkins、GitLab CI），实现自动构建、测试与部署
五、注意事项
- 避免滥用 Cherry-Pick：频繁使用会导致提交历史碎片化，建议仅在必要时使用
- 测试优先：合并到
master或release前必须通过自动化测试与人工验收
- 记录来源信息：使用
git cherry-pick -x在提交信息中记录原提交哈希，便于追溯
- 团队协作规范：统一分支命名（如
feature/20240314-payment）与合并流程，减少沟通成本
六、总结
- Cherry-Pick 是精准工具：适合紧急修复或选择性移植代码，但需谨慎处理依赖关系。
- Merge 是全局操作：适合功能全量发布或长期协作开发。
- 流程需适配团队：根据项目规模（单体 vs 微服务）和发布节奏（瀑布 vs 敏捷）选择 Git Flow 或 GitHub Flow 等策略。
这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并（
git merge）。另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 Cherry pick。
git branch -r
git checkout -b 本地分支名 origin/远程分支名
solve merge into problem in case of any conflict
# 1. 创建临时备份分支 git branch backup-feature-20250313
# 2. 合并 master 到当前开发分支 git merge master
# 3. 若合并后发现问题，切换回备份分支 git checkout backup-feature-20250313
# 4. 强制覆盖原开发分支（可选） git branch -f feature-branch
git branch -d backup-feature-20250313
🧪 场景设定：
你在
dev 分支上有这样的提交记录：你现在想从
dev 挑一些 commit 合并到 main 分支。✅ 情况1：连续的多个提交（比如从 C 到 E）
你想挑的提交：
操作命令：
✅ 解释：
c3c3c3c^是 C 的前一个提交（也就是 B）
- 所以这个命令会挑选：C、D、E
- 连续 commit 批量 cherry-pick 时，是两个 commit 之间用两个点：
^..
✅ 情况2：不连续的多个提交（比如 B 和 D）
你只想挑：
操作命令：
✅ 解释：
- 你手动写出需要的 hash，空格隔开
- Git 会按你写的顺序依次 cherry-pick
⚠️ 补充小细节
情况 | 写法 | 会包含哪些提交 |
连续 commit | hash1^..hash2 | 包括 hash1、hash2 之间所有提交（含头尾） |
不连续 commit | hash1 hash2 ... | 明确列出你想要的提交 |
🎁 小技巧：快速复制 hash
会展示简短 hash，右键复制粘贴就行，不用输完整的。
如果你告诉我你想挑哪几个，我也可以直接帮你写命令，不费劲～😎
分支流程
好的，我们来举一个完整的 实际开发流程例子，帮助你理解
master、dev、release、feature 分支是怎么协作的。🧪 场景：开发一个「订单导出」功能，并上线到生产
分支结构初始状态：
🚧 步骤一：创建 feature 分支开发功能
→ 在
feature/order-export 分支开发代码，提交若干次后完成。🔀 步骤二：合并功能到 dev
功能开发完成后，走 merge 或 PR 流程：
🚀 步骤三：准备上线，创建 release 分支
项目接入多个功能，准备上线：
→ 开始联调测试，修复 bug：
✅ 步骤四：上线，合并到 master 和 dev
测试通过，准备上线：
接着把 release 里的 bugfix 合并回 dev：
🔥 步骤五（可选）：线上出现 bug，创建 hotfix
上线后发现导出偶发乱码：
🌟 最终分支状态
master：v1.1.1，包含上线版本 + hotfix
dev：为下一个版本开发准备好了
feature/*和release/*分支可删除（已合并）