被破坏的数据实际上只是旧的提交消息，但 --force 不知道，并且也会愉快地删除其他数据 . 因此，将 --force 视为"I want to destroy data, and I know for sure what data is being destroyed."但是当提交已销毁的数据时，您通常可以从reflog中恢复旧的提交 - 数据实际上是孤立的而不是销毁的（尽管孤立的提交会被定期删除） .
如果要修改较旧的提交而不是最后一个提交，则需要在 Amending the message of older or multiple commit messages 部分使用 rebase 命令，如Github help page中所述
0
additional information for same problem if you are using bitbucket pipeline
编辑你的信息
git commit --amend
推到服务器
git push --force <repository> <branch>
然后在管道上添加--force到push命令
git ftp push --force
这将删除您之前的提交并推送您当前的提交 .
首次推送后删除--force
我在bitbucket管道上试了一下它的工作正常
6
说啊 ：
git commit --amend -m "New commit message"
然后
git push --force
36
Use these two step in console :
git commit --amend -m "new commit message"
and then
git push -f
Done :)
328
另一种选择是创建一个额外的"errata commit"（和push），它引用包含错误的提交对象 - 新的勘误提交也提供了更正 . 勘误提交是一个没有实质性代码更改但是重要提交消息的提交 - 例如，在自述文件中添加一个空格字符并使用重要提交消息提交更改，或使用git选项 --allow-empty . 它's certainly easier and safer than rebasing, it doesn't修改了真实的历史记录，它保持了分支树的清洁（如果你正在纠正最近的提交，使用 amend 也是一个不错的选择，但是对于旧的提交，勘误提交可能是一个不错的选择） . 这种类型的事情很少发生，仅仅记录错误就足够了 . 在将来，如果您需要在git日志中搜索功能关键字，原始（错误）提交可能不会出现，因为在原始提交中使用了错误的关键字（原始拼写错误） - 但是，关键字将出现在勘误表提交中，它将指向您具有拼写错误的原始提交 . 这是一个例子：
$ git log
commit 0c28141c68adae276840f17ccd4766542c33cf1d
Author: First Last
Date: Wed Aug 8 15:55:52 2018 -0600
Errata commit:
This commit has no substantive code change.
This commit is provided only to document a correction to a previous commit message.
This pertains to commit object e083a7abd8deb5776cb304fa13731a4182a24be1
Original incorrect commit message:
Changed background color to red
Correction (*change highlighted*):
Changed background color to *blue*
commit 032d0ff0601bff79bdef3c6f0a02ebfa061c4ad4
Author: First Last
Date: Wed Aug 8 15:43:16 2018 -0600
Some interim commit message
commit e083a7abd8deb5776cb304fa13731a4182a24be1
Author: First Last
Date: Wed Aug 8 13:31:32 2018 -0600
Changed background color to red
1
命令 1 .
git commit --amend -m "New and correct message"
然后，
命令 2 .
git push origin --force
3
应该注意的是 if you use push --force with mutiple refs, they will ALL be modified as a result. 请务必注意git repo配置的位置 . 幸运的是，通过指定要更新的单个分支，有一种方法可以稍微保护该过程 . 从git手册页中读取：
11 回答
聚会可能会迟到，这是我在这里看不到的答案 .
Step1 ：
git rebase -i HEAD~n为受影响的最后n提交进行交互式rebase .git会弹出一个编辑器来处理这些提交，注意这个命令：
# r, reword = use commit, but edit the commit message，这正是我们需要的 .Step2 ：对于要更新消息的提交，将
pick更改为r. 保存并关闭编辑器 .Step3 ：在以下提交文件中，根据需要更新提交消息
Step4 ：在所有提交后更新msgs . 您可能想要
git push -f来更新遥控器 .然后编辑然后在当前窗口中更改消息 . 之后呢
这对我很有用，
git checkout origin / branchname
如果你已经在分支机构，那么最好做拉或退刀
要么
以后你可以简单地使用
或者如果你想打开文本编辑器然后使用
如果你有很多评论我会更喜欢使用文本编辑器 . 您可以使用命令设置首选文本编辑器
无论如何，当您完成更改提交消息后，保存并退出
然后跑
而且你已经完成了
改变历史
如果它是最近的提交，您可以简单地执行此操作：
这会使编辑器显示最后一次提交消息，并允许您编辑消息 . （如果要删除旧邮件并使用新邮件，可以使用
-m. ）推
然后当你推动时，执行以下操作：
或者您可以使用“”：
或者您可以使用
--force：使用这些命令时要小心 .
如果其他人将更改推送到同一分支，您可能希望避免破坏这些更改 .
--force-with-lease选项是最安全的，因为如果有任何上游更改它将中止（如果未明确指定分支，Git将使用默认推送设置 . 如果您的默认推送设置为“匹配”，则您可能同时销毁多个分支上的更改 .
之后拉/取
任何已经拉过的人现在都会收到一条错误消息，并且他们需要通过执行以下操作来更新（假设他们自己没有进行任何更改）：
使用
reset --hard时要小心 . 如果您对分支进行了更改，那么这些更改将被销毁 .关于修改历史记录的说明
被破坏的数据实际上只是旧的提交消息，但
--force不知道，并且也会愉快地删除其他数据 . 因此，将--force视为"I want to destroy data, and I know for sure what data is being destroyed."但是当提交已销毁的数据时，您通常可以从reflog中恢复旧的提交 - 数据实际上是孤立的而不是销毁的（尽管孤立的提交会被定期删除） .如果您没有破坏数据，请远离
--force... bad things might happen .这就是
--force-with-lease更安全的原因 .如果要修改较旧的提交而不是最后一个提交，则需要在 Amending the message of older or multiple commit messages 部分使用
rebase命令，如Github help page中所述additional information for same problem if you are using bitbucket pipeline
编辑你的信息
推到服务器
然后在管道上添加--force到push命令
这将删除您之前的提交并推送您当前的提交 .
我在bitbucket管道上试了一下它的工作正常
说啊 ：
然后
Use these two step in console :
and then
Done :)
另一种选择是创建一个额外的"errata commit"（和push），它引用包含错误的提交对象 - 新的勘误提交也提供了更正 . 勘误提交是一个没有实质性代码更改但是重要提交消息的提交 - 例如，在自述文件中添加一个空格字符并使用重要提交消息提交更改，或使用git选项
--allow-empty. 它's certainly easier and safer than rebasing, it doesn't修改了真实的历史记录，它保持了分支树的清洁（如果你正在纠正最近的提交，使用amend也是一个不错的选择，但是对于旧的提交，勘误提交可能是一个不错的选择） . 这种类型的事情很少发生，仅仅记录错误就足够了 . 在将来，如果您需要在git日志中搜索功能关键字，原始（错误）提交可能不会出现，因为在原始提交中使用了错误的关键字（原始拼写错误） - 但是，关键字将出现在勘误表提交中，它将指向您具有拼写错误的原始提交 . 这是一个例子：命令 1 .
然后，
命令 2 .
应该注意的是 if you use push --force with mutiple refs, they will ALL be modified as a result. 请务必注意git repo配置的位置 . 幸运的是，通过指定要更新的单个分支，有一种方法可以稍微保护该过程 . 从git手册页中读取：