git merge 默认保留原始作者信息，但仅限非 squash 的三方合并；快进合并不产生新提交，故不修改作者信息；squash merge 会丢失原始多作者信息，需手动在提交信息中添加 co-authored-by 追溯署名。
git merge 会保留原始作者信息吗
会，但仅限于 git merge（非 squash）操作。默认的三方合并（git merge dev）会在新提交中完整保留 dev 分支上所有原始提交的 author 和 committer 字段——包括姓名、邮箱、时间戳。你看到的合并提交本身（merge commit）只新增一个 committer，不影响子提交历史。
常见错误现象：执行 git merge 后用 git log --pretty=fuller 查看，发现某些提交的 Author 显示为当前用户，而非原作者。这通常是因为：
– 原提交的邮箱未在本地 git config user.email 中配置（Git 不校验邮箱真实性，但部分 GUI 工具或 CI 会按此过滤）；
– 使用了 git pull（等价于 fetch + merge），而 pull 的 rebase 模式被意外启用（见下一条）；
– 远程分支被 rebase 过，原始提交已被重写（此时“原作者”实际是重写者）。
为什么 git merge --ff-only 有时会丢作者信息
--ff-only 是快进合并，不产生新提交，只是移动 HEAD 指针。它本身不修改任何提交对象，所以不会“丢”作者信息——但前提是目标分支的提交链未被重写过。
真正的问题在于：如果 dev 分支曾被 git rebase 或 filter-branch 重写过，那么即使走快进，你看到的提交也已是新对象（commit hash 变了），其 author 字段可能已被覆盖（比如批量改邮箱脚本误操作）。此时 git log 显示的作者，是重写时设定的值，不是原始提交者。
验证方法：
– 对比重写前后的某个提交哈希：git show --pretty=fuller <old-hash></old-hash> vs git show --pretty=fuller <new-hash></new-hash>；
– 检查是否有人执行过类似 git filter-branch --env-filter 'export GIT_AUTHOR_NAME="xxx"' ... 的命令。
如何避免 squash merge 丢失原始作者
Squash merge 天然丢弃原始提交历史：它把整个分支的变更压缩成一个新提交，只保留 committer（执行 merge 的人），author 字段可手动指定，但原始多作者信息无法还原。
如果你必须用 squash（如 GitHub PR 默认设置），又想追溯署名：
– 在 PR 描述里明确列出所有贡献者，例如 “@alice @bob added feature X”；
– 合并后手动在 commit message 中追加 Co-authored-by: Alice <alice></alice>（GitHub 识别该格式并关联贡献者）；
– 禁用自动 squash，改用 rebase and merge：它保持每个提交独立，作者信息 100% 保留，只是线性化历史（注意：需确保 dev 分支未被多人共同推送，否则 rebase 会污染他人本地分支）。
git rebase 后如何恢复原始 author 信息
不能“恢复”，因为 rebase 创建的是全新提交对象。但你可以提前规避：
– 执行 git rebase -i 前，先运行 git log --pretty='%h %an %s' origin/main..HEAD 导出原始作者列表；
– 在交互式编辑器中，对每条 pick 行，改为 edit，保存退出后逐个用 git commit --amend --author="Original Name <original>" --no-edit</original> 修正；
– 或使用脚本批量处理（需谨慎）：git filter-branch --env-filter 'if [ "$GIT_COMMIT" = "abc123" ]; then export GIT_AUTHOR_NAME="..."; fi' HEAD；
– 更安全的做法是：团队约定禁止对已推送分支做 rebase，改用 merge 或 cherry-pick 单个提交。
最易被忽略的一点：Git 从不验证邮箱真实性，author 字段完全由客户端写入。你看到的“作者”，只是提交对象里存的字符串——它可能和 GitHub 账号、公司 LDAP 完全无关。真要绑定身份，得靠外部机制（如 GPG 签名、CI 强制检查邮箱域名）。
