Git提交后追加修改的操作指南实用指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Git提交后追加修改的操作指南”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

理解这一步时，在开发时经常会遇到在git commit后，又把文件修改了一下的情况，此时要如何操作才能避免提交多个commit呢？

前面你已经走了这两步：

git add .
git commit -m "fix:修改了一个bug"

结合项目来看，此时你提交的代码还在本地暂存区，随后你又发现没改完，又有新修改文件产生。

下面，你的操作步骤应该是这样的：

基本步骤

将修改的文件添加到暂存区（Staging Area）

落到代码里，这里还是和你平时提交前一样，采用 git add 命令。

# 添加某个特定文件
git add <文件名>
# 或者，添加所有当前修改的文件
git add .

执行修改提交（Amend Commit）

这会把你刚刚添加的修改，合同时到上一次的commit提交中，并且会重写（覆盖） 上一次的提交。

git commit --amend

git commit --amend 后会发生什么？

落到代码里，如果你的文本编辑器（如 Vim, VSCode 等）弹出来了一段文本内容，不要慌，你会看到上一次提交的提交信息。

这时你能够 直接保存退出(一般是输入:wq)，就采用原来的提交信息。或者也能够修改提交信息，随后保存退出，相当于这是你修改上次写错的提交信息的机会。

3. 命令执行完成后，commit被重置

从实现思路看，你之前的那次提交（我称之为 Commit A）就会被一个新的提交（姑且称之为 Commit A‘）所替代。Commit A‘ 包含了原来的更改和你刚刚添加的更改。

最后效果：你的提交历史中看起来只有一次提交，但这次提交包含了你后来追加的更改，很nice。

重要提醒（尤其涉及远程仓库时）

结合项目来看，涉及到远程仓库时，我都是很小心的，因为这可能会污染同事的代码，前面几步都是在本的操作。这里说一下涉及远程仓库时需留意的地方：

如果已经推送到远程了怎么办？

如果你已经将原来的提交 git push 到了远程仓库，那么在你本地执行 --amend 后，你的本地历史就和远程历史不一致了。

这时你需采用 git push --force-with-lease（建议）或 git push --force 来强制覆盖远程仓库的历史。

请谨慎采用 force push理解这一步时，，因为这会影响此项目中的其他程序员——如果他们已经基于你原来的提交进行了开发，强制推送会打乱他们的流程。通常只在确定只有你一人在修改这个分支时才能这么做。

操作流程总结

# 1. 提交后，发现还有需要修改的地方，继续修改文件
# 2. 将修改后的文件加入暂存区
git add <file(s)>
# 或者
git add .

# 3. 将修改追加到上一次提交
git commit --amend
# (在弹出的编辑器中确认或修改提交信息，然后保存退出)

# 4. 【如果之前的提交已经推送到远程】需要强制推送更新
git push --force-with-lease

一般情况下，只需完成前两步 git add 和 git commit --amend 即可。

到此这篇关于Git提交后追加修改的操作指南的文章就介绍到这了,更多相关Git提交后追加修改操作内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家！