rebase后如何解决冲突并保留原始提交时间？

Question

在执行 `git rebase`（尤其是交互式 rebase，如 `git rebase -i main`）过程中，若遇到冲突并手动解决后继续变基（`git add && git rebase --continue`），Git 默认会**重写提交对象**，导致所有被变基的提交 `author date` 和 `committer date` 均更新为当前时间——原始提交时间（即最初 `git commit` 时的时间戳）就此丢失。这不仅影响提交历史的可追溯性，更破坏了按时间线审计、CI/CD 时间敏感触发、或与外部系统（如 Jira、审计日志）时间对齐的需求。开发者常误以为 `--no-date` 或 `--ignore-date` 可保留原始时间，但这些参数实际仅作用于新提交，对 rebase 中重放的提交无效。那么：**如何在成功解决 rebase 冲突后，精准恢复每个提交的原始 author/committer 时间戳？** 这一问题在版本归档、合规审计及团队协作中尤为关键，却缺乏 Git 内置的一键方案。

Answer 1

```html

一、现象剖析：为什么 rebase 会“抹掉”原始时间戳？

Git 的 rebase 本质是「重放提交」（replay），而非「移动指针」。每次 git commit 创建的对象包含两个独立时间字段：author date（作者撰写时）与 committer date（实际提交/变基时）。交互式 rebase（git rebase -i main）在冲突后执行 git rebase --continue 时，Git 会调用 git commit --allow-empty 内部逻辑重建每个提交对象——此时 author date 被默认继承自原提交，但 committer date 强制更新为当前系统时间；更关键的是：若用户在解决冲突后执行了 git commit（而非 --continue），或使用了某些 Git GUI 工具，author date 也可能被意外覆盖。

二、认知纠偏：--ignore-date 为何失效？

• --ignore-date 仅影响 新创建的提交（如 git commit --ignore-date），对 rebase 中由 Git 自动调用的内部提交构造器无效；
• --no-date 同理，它将 author date 设为 Unix epoch（1970-01-01），完全背离目标；
• Git 未暴露 rebase 期间的 author/committer 时间覆写开关——这是设计取舍，非 bug。

三、技术路径全景图：四大可行策略对比

策略	适用场景	是否保留 author/committer	自动化程度	风险提示
① pre-rebase 元数据快照 + post-rebase 批量修正	高合规要求团队（金融/医疗）	✅ 完整双时间戳	⭐⭐⭐⭐	需提前部署钩子，依赖 git log --format=... 解析精度
② git filter-repo + commit-map 映射回填	已发生误 rebased 的紧急修复	✅ 可编程控制	⭐⭐⭐	需重写历史，强制推送，影响协作者
③ 自定义 rebase.exec 钩子（Git 2.38+）	CI/CD 流水线集成	✅ 原生支持	⭐⭐⭐⭐⭐	仅限新版本 Git，需配置 core.rebase.instructionFormat
④ 提交前冻结时间戳（git commit --date）	单次轻量修复	⚠️ 仅 author date 可控	⭐⭐	无法恢复 committer date，且不适用于 --continue 流程

四、实战方案①：pre-rebase 快照 + post-rebase 时间戳回填（推荐）

核心思想：在 rebase 开始前，用结构化方式持久化每个待变基提交的原始时间戳；冲突解决后，通过 git filter-repo 或自研脚本批量注入。

# 步骤1：生成时间戳快照（执行 rebase 前）
git log --format="%H %aI %cI" HEAD~5..HEAD > rebase-timestamps.txt

# 示例输出：
# abc123 2024-03-15T14:22:03+08:00 2024-03-15T14:22:03+08:00
# def456 2024-03-16T09:05:11+08:00 2024-03-16T09:05:11+08:00

# 步骤2：完成 rebase 后，用 Python 脚本解析并重写提交
python3 restore-timestamps.py --map rebase-timestamps.txt --ref HEAD~5..HEAD

五、深度机制：Git 内部如何存储与序列化时间？

Git 对象中时间戳以「Unix timestamp + timezone offset」形式存储（非 ISO8601 字符串），例如：author Junio C Hamano <[e-mail]> 1710512345 +0900。这意味着任何时间恢复方案必须：

1. 精确解析原始提交的 author 和 committer 行；
2. 避免时区转换错误（如将 +0800 错解为 UTC）；
3. 确保新对象哈希与原对象不同——这正是 rebase 不可逆的根源。

六、流程图：时间戳恢复自动化流水线

graph TD
  A[开发者发起 git rebase -i main] --> B{预检钩子触发}
  B -->|yes| C[自动执行 git log --format='%H %aI %cI' > timestamps.json]
  C --> D[保存至 .git/rebase-meta/]
  D --> E[进入交互式 rebase]
  E --> F{发生冲突？}
  F -->|yes| G[手动解决 → git add → git rebase --continue]
  F -->|no| H[rebase 完成]
  G --> I[检测到 .git/rebase-meta/timestamps.json 存在]
  I --> J[调用 restore-timestamps.py 注入原始时间]
  J --> K[强制更新 reflog 并校验 SHA256]

七、企业级实践建议：构建时间可信链

• 在 Git 服务器（如 GitLab/GitHub Enterprise）启用 commit-signing，结合时间戳服务（RFC 3161 TSA）锚定 author date；
• 将 git log --format='%H %aI %cI %s' 输出接入 SIEM 系统，形成审计事件时间基线；
• 在 CI 流水线中增加 git verify-commit --raw 校验，拒绝 committer date 早于 author date 的异常提交。

八、避坑指南：高频失败场景与诊断命令

当时间恢复失败时，请立即运行以下诊断：

# 查看某提交原始对象内容（绕过 reflog 缓存）
git cat-file -p <commit-hash>

# 比较 rebase 前后同一逻辑变更的 author date 差异
git show --pretty=format:'%H %aI %cI %s' <old-sha> <new-sha>

# 检查 reflog 中是否残留原始提交引用
git reflog --date=iso | grep 'rebase.*start'

九、演进趋势：Git 社区的官方回应与替代方案

Git 官方在 2023 年邮件列表中明确表示：「保留 committer date 是反模式，因 rebase 本质是历史重写」。但社区已提出 RFC #127（Preserve Committer Timestamp in Rebase），部分发行版（如 Git for Windows v2.43+）已实验性支持 git config --global rebase.preserveCommitters true。与此同时，git sequencer 子系统正重构为可插拔架构，为未来第三方时间管理插件预留接口。

十、结语：时间即契约，而非装饰

在 SOC2、ISO 27001、GDPR 等合规框架下，提交时间戳不是元数据冗余，而是软件供应链中不可抵赖的「数字契约」。每一次 git rebase --continue 都是对历史真实性的再确认——而我们的工具链，必须从「容忍丢失」转向「主动捍卫」。

```