Git cherry-pick 与分支重置技术实现代码健全性保障下的提交记录精简
代码健全性保障：上市审查中的 Git 提交记录整理方案（核心功能提交筛选流程）
一、背景与目的
我司正处于上市筹备阶段，券商需对核心系统进行 Git 代码审查，并基于提交记录生成测试报告。由于原始提交记录包含大量细节性修改（如 Bug 修复、格式调整等），不利于清晰呈现核心功能与模块的开发脉络，因此需要通过整理，筛选出与大功能、大模块相关的关键提交记录，确保审查过程中能准确反映系统开发的核心逻辑与迭代路径，同时完全保留代码完整性，不影响系统实际运行与后续开发。
二、核心目标
创建一个 “净化版” 临时分支，仅保留与核心功能、大模块相关的关键提交记录（隐藏细节性提交），且代码内容与原始分支完全一致，既满足券商审查对提交记录的清晰性要求，又不修改原始代码仓库的历史，保障代码健全性与可追溯性。
三、前期准备
1. 确保工作区干净
操作前需提交或暂存所有未完成的修改，避免在整理过程中产生冲突，保障代码状态稳定：
# 检查工作区状态，确认是否有未提交的修改git status# 如有未提交内容，先暂存并提交（备注需体现“上市审查准备”，便于追溯）git add . && git commit -m "上市审查准备：暂存当前未提交修改"
2. 梳理关键提交记录
与团队共同梳理核心系统的功能模块清单（如用户系统、交易模块、风控模块等），并对照原始提交历史，筛选出与各模块开发、核心功能实现相关的关键提交，记录其哈希值（按时间从旧到新排序）：
# 以图形化简洁格式展示完整提交历史（包含分支关系与提交哈希）git log --oneline --graph --decorate
示例梳理结果（假设核心模块相关提交为 b2、b4、b6）：
b7 细节优化：调整日志格式（非核心，隐藏）b6 交易模块：完成实时清算功能（核心，保留）→ 哈希：b6b5 Bug修复：修复表单校验异常（非核心，隐藏）b4 用户系统：实现身份认证与权限管理（核心，保留）→ 哈希：b4b3 样式调整：优化后台页面布局（非核心，隐藏）b2 基础框架：搭建核心系统架构（核心，保留）→ 哈希：b2b1 初始化：创建项目仓库（基础，保留或隐藏根据审查需求）
四、详细操作步骤
步骤 1：基于原分支创建审查专用临时分支（保留代码）
从核心系统所在的主分支（如 main 或 master）创建一个临时分支，用于存放整理后的提交记录，确保原始分支不受影响：
# 基于当前主分支创建审查专用分支（命名建议包含“review”或“listing”标识）git checkout -b listing-review-clean
- 此时新分支
listing-review-clean与主分支代码完全一致，提交历史也完全相同，为后续整理奠定基础。
步骤 2：清空临时分支的提交历史（保留代码）
将临时分支的提交历史重置到 “无任何提交” 的初始状态，但保留工作区所有代码（核心操作，保障代码不丢失）：
# 查找主分支的第一个提交（初始提交）的哈希值（如b1）# 若不确定，可通过以下命令查看最早的提交记录git log --reverse --oneline | head -1 # 输出示例：b1 初始化：创建项目仓库# 重置临时分支到初始提交之前（彻底清空历史，仅保留代码）git reset --soft b1~1
-
--soft参数是关键：仅清空提交历史记录，工作区的代码文件、文件夹及暂存区状态完全保留，确保核心系统代码健全性。 -
执行后，
git log会显示 “无提交记录”，但通过ls或文件管理器查看，所有代码文件均完整存在。
步骤 3：重新应用关键提交（重建核心历史）
按时间从旧到新的顺序，使用 git cherry-pick 将筛选出的核心提交逐个 “复制” 到临时分支，重建与核心功能相关的提交历史：
# 1. 先应用最早的核心提交（如基础框架搭建b2）git cherry-pick b2# 2. 依次应用后续核心提交（如用户系统开发b4）git cherry-pick b4# 3. 最后应用最新的核心提交（如交易模块清算功能b6）git cherry-pick b6
若出现冲突（如提交间存在依赖关系）：
- 终端会提示冲突文件路径（如
src/trade/clearing.js），打开文件找到冲突标记：
<<<<<<< HEAD（当前临时分支状态）[本地代码]=======[待应用提交b6的代码]>>>>>>> b6（交易模块：完成实时清算功能）
-
与团队相关开发人员确认代码逻辑，保留正确的实现（需符合核心系统功能设计），删除冲突标记。
-
标记冲突已解决：
git add src/trade/clearing.js # 替换为实际冲突文件路径
- 继续完成当前提交的应用：
git cherry-pick --continue
- 若需放弃本次操作（如冲突无法短时间解决）：
git cherry-pick --abort # 回到操作前的临时分支状态，重新梳理提交顺序
五、验证与确认
1. 检查提交历史（仅保留核心记录）
# 查看临时分支的提交历史，确认仅显示筛选的核心提交git log --oneline --graph
- 预期输出（按时间顺序排列的核心提交）：
b6 交易模块：完成实时清算功能b4 用户系统：实现身份认证与权限管理b2 基础框架：搭建核心系统架构
2. 确认代码完整性与一致性
# 对比临时分支与主分支的代码差异（确保无任何区别）git diff main # 替换为核心系统所在的原分支名称
- 若命令无输出，说明代码完全一致，核心系统功能不受影响；若有差异，需排查
cherry-pick过程是否有误。
3. 功能验证（关键步骤）
由于涉及上市审查，需通过自动化测试或人工验证，确认临时分支的代码可正常运行，核心功能模块无异常：
# 示例：执行项目测试脚本（根据实际项目调整）npm run test # 或其他测试命令，确保所有核心测试用例通过
六、审查配合与后续管理
1. 提供审查分支
将整理后的临时分支 listing-review-clean 推送到远程仓库（如需券商直接查看）：
# 推送临时分支到远程（命名建议与本地一致，便于识别）git push -u origin listing-review-clean
- 告知券商审查人员：该分支仅包含核心功能相关提交，代码与生产环境完全一致，可用于生成测试报告。
2. 保留原始分支与操作记录
-
原始主分支（如
main）的完整历史需妥善保留，作为代码开发的原始凭证，满足上市审查的追溯要求。 -
建议将本次整理过程（包括筛选的核心提交清单、操作时间、执行人）记录在项目文档中，便于后续审计。
3. 后续更新（如审查需补充提交）
若券商审查过程中要求补充其他核心提交，重复步骤 3，将新增的关键提交哈希应用到临时分支：
git checkout listing-review-clean # 切换到临时分支git cherry-pick 新增核心提交哈希 # 如补充“风控模块”相关提交b8git push origin listing-review-clean # 推送更新
4. 审查完成后处理
审查结束后，临时分支可保留作为历史记录，或根据需要删除（不影响原始代码）：
# 如需删除本地临时分支git checkout main # 先切换到其他分支git branch -D listing-review-clean# 如需删除远程临时分支（确认不再需要后）git push origin --delete listing-review-clean
七、方案优势
-
代码健全性保障：全程保留核心系统代码，与原始分支完全一致，不影响功能运行。
-
提交记录清晰化：仅展示与大功能、大模块相关的关键提交，便于券商快速理解开发脉络。
-
安全性高：不修改原始仓库历史，所有操作可追溯，符合上市审查对代码管理的规范性要求。
-
灵活可控：可根据审查需求随时补充或调整提交记录，适应不同阶段的审查要求。