解决git rebase操作后推送远端分支不成功的问题＜转＞_rebase 分支之后上传 落后于远程分支

<转载>原文：https://blog.csdn.net/ManyPeng/article/details/81095744

前段时间在工作中同事在rebase时遇到一个问题来问我，今天突然想起来觉得有必要记录一下。

在我们日常工作中，经常使用git座位代码管理工具，而且一个项目通常由多人开发，我当时所在组的git管理策略是master分支作为主干的无bug分支（测试验证通过），每个开发在自己的个人分支上进行开发，当开发完毕时rebase master分支，然后进行提测，测试通过后，再发起merge request合并到maste分支，这样就可以保证master分支一直是无bug分支，而且其他分支可以放心的进行rebase操作。

 

分析&解决方案

而在这过程中就遇到了如下问题，举一个简单的例子说明如下： 最开始分支只有一个master上面有A<--B<--C三个分支，在C提交上开出了一个新的feature分支 并在其上进行了开发，而在feature分支进行开发并commit两次后，master分支也发生了变化，当前git仓库如下图所示：
A<--B<--C<-------F<--G  (master)
                \
                 D<--E  (feature)

此时如果你在master分支上，可以直接进行 git push origin master  操作更新master分支；如果你在feature分支上，可以直接进行 git push origin feature 操作更新feature分支

但是接下来，按照前文所说的的工作场景，你现在完成开发，需要在feature分支上rebase master分支之后进行提测，所以你在本地的feature分支上执行了 git rebase msater 命令，于是你现在本地的分支结构变成了下图所示的样子：

A<–B<–C<–F<–G (master)
                            \
                             D’<–E’(feature)

此时已经在本地完成了rebase操作，但是远端仓库还是图一的初始状态，所以你需要把你本地的feature分支推送到远端，此时执行 git push origin feature 会报错。这是因为git的push操作默认是假设远端的分支和你本地的分支可以进行fast-forward操作，换句话说就是这个push命令假设你的本地分支和远端分支的唯一区别是你本地有几个新的commit，而远端没有，比如下图这种情况：

1<–2<–3  (远端)
              \
              4<–5  (本地)

但是由于进行了rebase操作，现在远端和本地的feature分支的状况是这样的：

A<–B<–C<—F<–G<–D’<–E’  (本地feature分支)
                \
                 D<–E  (远端feature分支)

这种情况下是不能进行fast-forwad模式的合并操作的，所以当执行 git push origin feature 命令时会报一个错误。

解决办法

1. feature分支只有你一个人在开发
   
   此时没有其他人会进行提交操作，那么可以直接进行强制推送 git push --force origin feature ，–force可以直接理解为用你本地分支的状态区覆盖掉远端origin分支的状态，也就是执行过后，本地的分支什么样，远端分支就什么样
2. feature分支有多人开发
   
   此时如果你贸然的使用–force命令，会有覆盖掉其他人提交代码的风险。比如，小明和小红两个人同时在feature分支上进行开发，小明已经在feature分支上提交了一部分代码，而小红此时执行了rebase操作，所以如果想要推送到远端仓库就必须使用 - -force 参数，而小红推送成功之后就会覆盖掉小明提交的代码（前面说过–force就是用本地状态覆盖掉远端状态）。在这种情况下，推荐另外一种更安全的命令  git push --force-with-lease origin feature  使用该命令在强制覆盖前会进行一次检查如果其他人在该分支上有提交会有一个警告，此时可以避免福改代码的风险。 

总结：不管当前分支是否只有自己在使用，在rebase之后，需要强制推送到远端分支时，使用  git push --force-with-lease origin feature  参数来保证分支安全。