代码健全性保障：上市审查中的 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

若出现冲突（如提交间存在依赖关系）：

1. 终端会提示冲突文件路径（如 src/trade/clearing.js），打开文件找到冲突标记：

<<<<<<< HEAD（当前临时分支状态）[本地代码]=======[待应用提交b6的代码]>>>>>>> b6（交易模块：完成实时清算功能）

1. 与团队相关开发人员确认代码逻辑，保留正确的实现（需符合核心系统功能设计），删除冲突标记。

2. 标记冲突已解决：

git add src/trade/clearing.js  # 替换为实际冲突文件路径

1. 继续完成当前提交的应用：

git cherry-pick --continue

1. 若需放弃本次操作（如冲突无法短时间解决）：

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

七、方案优势

1. 代码健全性保障：全程保留核心系统代码，与原始分支完全一致，不影响功能运行。

2. 提交记录清晰化：仅展示与大功能、大模块相关的关键提交，便于券商快速理解开发脉络。

3. 安全性高：不修改原始仓库历史，所有操作可追溯，符合上市审查对代码管理的规范性要求。

4. 灵活可控：可根据审查需求随时补充或调整提交记录，适应不同阶段的审查要求。