git commit --amend 只能修改最近一次本地提交的提交信息和暂存区内容，不能修改已推送的提交历史本身；它生成新commit对象（sha变更），但保留父提交、作者时间等元数据，无法修改更早提交——须用git rebase -i。
git commit --amend 能改什么，不能改什么
git commit --amend 只能修改**最近一次本地提交的提交信息（message）和暂存区内容**，不能改已推送到远程的提交历史本身——除非你强制推送。它本质是用一个新提交替换旧提交（SHA-1 值会变），但保留父提交、作者时间、作者邮箱等元数据（除非显式指定 --author 或 --date）。
常见误操作：在 git commit --amend 后直接 git push，结果报错 rejected - non-fast-forward。这是因为远程分支指向的是旧提交，而本地现在指向一个全新 SHA，Git 拒绝覆盖。
- 能改：提交信息（
-m "new message"）、暂存区内容（比如漏git add的文件）、作者信息（加--author="Name <email>"</email>）、提交时间（加--date="..."） - 不能改：已
push到远程的提交记录（除非后续git push --force-with-lease） - 慎用场景：该提交已被他人基于开发，或已触发 CI/CD 流水线
修改已推送的最近一次提交信息（含强制推送）
如果提交已经 git push 过，改完后必须用 git push --force-with-lease 替换远程引用。相比裸 --force，--force-with-lease 会检查远程分支自你上次 fetch 后是否被别人更新过，避免误覆盖他人工作。
完整流程：
- 执行
git commit --amend -m "修正后的提交信息" - 确认当前分支与远程对应（如
origin/main），再运行git push --force-with-lease origin main - 若提示
unable to force push，说明远程已有新提交——此时不应强行覆盖，应先git pull合并，或协调团队
注意：--force-with-lease 不会覆盖他人新增的提交；而 --force 会无条件覆盖，生产环境禁用。
想改的不是最后一次提交？用 git rebase -i
如果要修改倒数第二次、第三次……甚至更早的提交信息，git commit --amend 就失效了，得用交互式变基：git rebase -i HEAD~n（n 是你想追溯的提交数）。
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
例如改倒数第 3 次提交：
git rebase -i HEAD~3
编辑器打开后，把目标那行的 pick 改成 reword（别写成 edit，后者会停在那让你改代码，改信息用 reword 更安全），保存退出。Git 会逐个打开需要重写的提交让你输入新信息。
- 风险点：所有被 rebase 的提交 SHA 都会变，其后的所有分支指针、标签、CI 构建缓存都可能失效
- 如果过程中出错（比如冲突未解决就继续），用
git rebase --abort回退到原始状态 - 改完后同样需
git push --force-with-lease，且要确保没人正基于这些旧提交开发
为什么 git push --force-with-lease 比 --force 安全
--force-with-lease 底层依赖一个“期望引用值”：它默认假设远程分支的最新 SHA 和你本地 fetch 时一致。一旦有人在你 fetch 后又 push 了新提交，这个假设失败，命令直接中止，不执行强制覆盖。
而 --force 完全跳过校验，相当于说“不管远程现在是什么，全按我的来”。在多人协作中，这极易导致他人提交丢失。
一个容易被忽略的细节：git push --force-with-lease 默认只校验当前分支的远程引用。如果你同时维护多个跟踪分支，或用了 git branch --set-upstream-to 但没同步最新状态，仍可能误判。建议每次 force 前先 git fetch。
