cherry-pick新提交的Author是原作者，Committer是当前操作者；需用--author="Name"或--no-commit后amend修正，否则易致权限校验失败或审计不通过。
别急着用或，先确认你真正要解决的是什么问题——是本地误提交？是想把某个修复搬到另一个分支？还是需要清理提交历史？用错命令可能让同事的直接失败。
git
cherry-pick 为什么挑完提交后 author 不对
默认情况下，
生成的新提交，
是原提交作者，
是当前操作者。这在跨团队合入 hotfix 时容易触发权限校验失败或审计不通过。
临时修正：加
参数暂存变更，再执行
批量统一：直接加
（注意双引号包裹），例如
验证方式：运行
，检查
和
字段是否符合预期
关键提醒：修改
后，新提交哈希必然变化，不能认为“内容一样就是同一个提交”
git rebase 在公共分支上强推会出什么事
一旦你在
或
这类多人共享分支上执行
并
，所有已基于旧历史工作的同事都会遇到
报错，强行
可能丢失本地提交，甚至引发代码覆盖。
Git
程序猿必备版本控制工具
下载
安全前提：只在自己独占的开发分支（如
）上使用
同步主干推荐替代方案：用
，保留可追溯的合并点
如果必须变基（比如整理本地提交），务必先
备份当前状态
远程分支被强推后，同事需手动重置：先
，再
（仅限确认无本地未推送提交时）
git reset --soft、--mixed、--hard 的实际影响差异
三者本质都是移动
指针，区别在于是否连带重置暂存区和工作区。最容易踩坑的是误用
导致未提交改动永久丢失。
：只回退
，代码修改和暂存状态都保留，适合改写提交信息或合并多次
（默认）：回退
+ 重置暂存区，但工作区文件不变，适合重新选择哪些文件要提交
：三者全清空，工作区未提交改动直接消失，
永远不要对已有远程记录的提交用这个
查漏技巧：执行前先运行
和
，确认工作区是否有未保存的关键修改
最常被忽略的一点：无论
还是
，只要涉及提交重写，就一定改变 SHA-1 哈希值。这意味着 CI 流水线里基于旧哈希的缓存、PR 关联、甚至某些自动化部署脚本，都可能失效——不是功能出错，而是“找不到那个提交”了。
git reset --hardgit rebasepullcherry-pickAuthorCommitter--no-commitgit commit --amend --author="Name " --author="Name " git cherry-pick a1b2c3d --author="Alice " git log --pretty=fuller -n 1AuthorCommitauthormainrelease/2.3git rebasegit push -fnon-fast-forwardpullfeature/login-uirebasegit merge origin/maingit checkout -b tmp-backupgit fetch origingit reset --hard origin/mainHEAD--hard--softHEADadd--mixedHEAD--hardgit statusgit diffcherry-pickrebase