git push -f？git reset后导致git push需要加-f的问题

大家好，今天给各位分享git push -f的一些知识，其中也会对git reset后导致git push需要加-f的问题进行解释，文章篇幅可能偏长，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在就马上开始吧！

修改已push到远端的commit

背景：当我们将commit提交到远端后,发现提交的commit message并不符合规范，需要修改，就需用到以下方法进行修改。

1.修改最近一次提交commit message

直接使用命令 git commit--amend进入 vi编辑模式

按i进入编辑模式，直接修改commit信息，按esc再:wq保存退出

git push到远程仓库

2.修改历史commit message

先使用git log查出你所需要修改的commit位置，比如倒数第三条

使用命令：git rebase-i HEAD~3（其中3就是commit倒数位置）进入vi编辑页面

其中git log中倒数第n条就显示在该编辑页面的最新第1条

按i进入编辑模式，将需要更改的commit的pick改成e/edit，按esc再:wq保存退出

如遇到：(dev|REBASE 1/3)，则只需在需要修改的rebase序号(此处就是1)是执行git commit--amend

进入VI编辑页面，修改commit信息，按esc再:wq保存退出

然后执行git rebase--skip跳过不需要修改的rebase分支，执行成功。

最后执行git rebase--continue命令完成rebase修改

最终push到远程，至此，修改完成。

tips:若进行到(dev|REBASE 1/3),中的一个阶段想退出此流程，执行命令git rebase--abort退出rebase到主分支

push到远端时，若执行git push,则只会在之前的commit记录后追加一条记录，但不会更新之前的commit信息

若执行git push-f，强制推送，则会更新之前的旧commit信息，进行覆盖

git reset后导致git push需要加-f的问题

打入补丁A，COMMIT后PUSH到服务器，这时候HEAD是节点1-A。

Reset后，打入正确补丁，PUSH-F到服务器，就会把刚才HEAD的节点1-A删除掉，变成2-A了。

问题是：如果有人在你节点1-A的时候PULL了，然后你把1-A删除换成了2-A，下次再PULL的时候，因为他是有节点1-A的，那就会出现冲突。

最正确的解决方法是，在1-A的节点上，再打一次补丁，变成1-B，然后用rebase-i把两个commit merge到一起就可以了。

Git不要只会pull和push,试试这5条提高效率的命令

使用 Git作为代码版本管理，早已是现在开发工程师必备的技能。可大多数工程师还是只会最基本的保存、拉取、推送，遇到一些commit管理的问题就束手无策，或者用一些不优雅的方式解决。

本文分享我在开发工作中实践过的实用命令。这些都能够大大提高工作效率，还能解决不少疑难场景。下面会介绍命令，列出应用场景，手摸手教学使用，让同学们看完即学会。

官方文档

git教程

stash命令能够将还未 commit的代码存起来，让你的工作目录变得干净。

我猜你心里一定在想：为什么要变干净？

应用场景：某一天你正在 feature分支开发新需求，突然产品经理跑过来说线上有bug，必须马上修复。而此时你的功能开发到一半，于是你急忙想切到 master分支，然后你就会看到以下报错：

因为当前有文件更改了，需要提交commit保持工作区干净才能切分支。由于情况紧急，你只有急忙 commit上去，commit信息也随便写了个“暂存代码”，于是该分支提交记录就留了一条黑历史...(真人真事，看过这种提交)

如果你学会 stash，就不用那么狼狈了。你只需要：

就这么简单，代码就被存起来了。

当你修复完线上问题，切回 feature分支，想恢复代码也只需要：

当有多条 stash，可以指定操作stash，首先使用stash list列出所有记录：

应用第二条记录：

pop，drop同理。

stash代码

填写备注内容，也可以不填直接Enter

在STASHES菜单中可以看到保存的stash

先点击stash记录旁的小箭头，再点击 apply或者 pop都可恢复 stash

官方文档

git教程

回退你已提交的 commit，并将 commit的修改内容放回到暂存区。

一般我们在使用 reset命令时，git reset--hard会被提及的比较多，它能让 commit记录强制回溯到某一个节点。而 git reset--soft的作用正如其名，--soft(柔软的)除了回溯节点外，还会保留节点的修改内容。

回溯节点，为什么要保留修改内容？

应用场景1：有时候手滑不小心把不该提交的内容 commit了，这时想改回来，只能再 commit一次，又多一条“黑历史”。

应用场景2：规范些的团队，一般对于 commit的内容要求职责明确，颗粒度要细，便于后续出现问题排查。本来属于两块不同功能的修改，一起 commit上去，这种就属于不规范。这次恰好又手滑了，一次性 commit上去。

学会 reset--soft之后，你只需要：

reset--soft相当于后悔药，给你重新改过的机会。对于上面的场景，就可以再次修改重新提交，保持干净的 commit记录。

以上说的是还未 push的commit。对于已经 push的 commit，也可以使用该命令，不过再次 push时，由于远程分支和本地分支有差异，需要强制推送 git push-f来覆盖被 reset的 commit。

还有一点需要注意，在 reset--soft指定 commit号时，会将该 commit到最近一次 commit的所有修改内容全部恢复，而不是只针对该 commit。

举个栗子：

commit记录有 c、b、a。

reset到 a。

此时的 HEAD到了 a，而 b、c的修改内容都回到了暂存区。

官方文档

git cherry-pick教程

将已经提交的 commit，复制出新的 commit应用到分支里

commit都提交了，为什么还要复制新的出来？

应用场景1：有时候版本的一些优化需求开发到一半，可能其中某一个开发完的需求要临时上，或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把 commit抽出来，单独处理。

应用场景2：有时候开发分支中的代码记录被污染了，导致开发分支合到线上分支有问题，这时就需要拉一条干净的开发分支，再从旧的开发分支中，把 commit复制到新分支。

现在有一条feature分支，commit记录如下：

需要把 b复制到另一个分支，首先把 commitHash复制下来，然后切到 master分支。

当前 master最新的记录是 a，使用 cherry-pick把 b应用到当前分支。

完成后看下最新的 log，b已经应用到 master，作为最新的 commit了。可以看到 commitHash和之前的不一样，但是提交时间还是保留之前的。

以上是单个 commit的复制，下面再来看看 cherry-pick多个 commit要如何操作。

上面的命令将 commit1和 commit2两个提交应用到当前分支。

上面的命令将 commit1到 commit2这个区间的 commit都应用到当前分支（包含commit1、commit2），commit1是最早的提交。

在 cherry-pick多个commit时，可能会遇到代码冲突，这时 cherry-pick会停下来，让用户决定如何继续操作。下面看看怎么解决这种场景。

还是 feature分支，现在需要把 c、d、e都复制到 master分支上。先把起点c和终点e的 commitHash记下来。

切到 master分支，使用区间的 cherry-pick。可以看到 c被成功复制，当进行到 d时，发现代码冲突，cherry-pick中断了。这时需要解决代码冲突，重新提交到暂存区。

然后使用 cherry-pick--continue让 cherry-pick继续进行下去。最后 e也被复制进来，整个流程就完成了。

以上是完整的流程，但有时候可能需要在代码冲突后，放弃或者退出流程：

回到操作前的样子，就像什么都没发生过。

不回到操作前的样子。即保留已经 cherry-pick成功的 commit，并退出 cherry-pick流程。

官方文档

将现有的提交还原，恢复提交的内容，并生成一条还原记录。

应用场景：有一天测试突然跟你说，你开发上线的功能有问题，需要马上撤回，否则会影响到系统使用。这时可能会想到用 reset回退，可是你看了看分支上最新的提交还有其他同事的代码，用 reset会把这部分代码也撤回了。由于情况紧急，又想不到好方法，还是任性的使用 reset，然后再让同事把他的代码合一遍（同事听到想打人），于是你的技术形象在同事眼里一落千丈。

学会 revert之后，立马就可以拯救这种尴尬的情况。

现在 master记录如下：

revert掉自己提交的 commit。

因为 revert会生成一条新的提交记录，这时会让你编辑提交信息，编辑完后:wq保存退出就好了。

再来看下最新的 log，生成了一条 revert记录，虽然自己之前的提交记录还是会保留着，但你修改的代码内容已经被撤回了。

在 git的 commit记录里，还有一种类型是合并提交，想要 revert合并提交，使用上会有些不一样。

现在的 master分支里多了条合并提交。

使用刚刚同样的 revert方法，会发现命令行报错了。

为什么会这样？在官方文档中有解释。

我的理解是因为合并提交是两条分支的交集节点，而 git不知道需要撤销的哪一条分支，需要添加参数-m指定主线分支，保留主线分支的代码，另一条则被撤销。

-m后面要跟一个 parent number标识出"主线"，一般使用 1保留主分支代码。

还是上面的场景，在 master分支 revert合并提交后，然后切到 feature分支修复好 bug，再合并到 master分支时，会发现之前被 revert的修改内容没有重新合并进来。

因为使用 revert后， feature分支的 commit还是会保留在 master分支的记录中，当你再次合并进去时，git判断有相同的 commitHash，就忽略了相关 commit修改的内容。

这时就需要 revert掉之前 revert的合并提交，有点拗口，接下来看操作吧。

现在 master的记录是这样的。

再次使用 revert，之前被 revert的修改内容就又回来了。

官方文档

如果说 reset--soft是后悔药，那 reflog就是强力后悔药。它记录了所有的 commit操作记录，便于错误操作后找回记录。

应用场景：某天你眼花，发现自己在其他人分支提交了代码还推到远程分支，这时因为分支只有你的最新提交，就想着使用 reset--hard，结果紧张不小心记错了 commitHash，reset过头，把同事的 commit搞没了。没办法，reset--hard是强制回退的，找不到 commitHash了，只能让同事从本地分支再推一次（同事瞬间拳头就硬了，怎么又是你）。于是，你的技术形象又一落千丈。

分支记录如上，想要 reset到 b。

误操作 reset过头，b没了，最新的只剩下 a。

这时用 git reflog查看历史记录，把错误提交的那次 commitHash记下。

再次 reset回去，就会发现 b回来了。

对我这种喜欢敲命令而不用图形化工具的爱好者来说，设置短命令可以很好的提高效率。下面介绍两种设置短命令的方式。

方式一

方式二

打开全局配置文件

写入内容

使用

本文主要分享了5个在开发中实用的 Git命令和设置短命令的方式。

文中列举的应用场景有部分不太恰当，只是想便于同学们理解，最重要的是要理解命令的作用是什么，活学活用才能发挥最大功效。

如果你也有一些实用的 Git命令也欢迎在评论区分享~

感谢您花时间阅读本文！我们希望通过对git push -f的问题进行探讨，为您提供了一些有用的见解和解决方案。如果您需要更多帮助或者有其他疑问，请不要犹豫与我们联系。