git rebase -i 后强制推到远端 （一）

一、git rebase 之后强推到远端

1.git commit太多次的弊端：

1.不利于代码 review
设想一下，你要做 code review ，结果一个很小的功能，提交了 60 多次，会不会有一些崩溃？

2.会造成分支污染
你的项目充满了无用的 commit 纪录，如果有一天线上出现了紧急问题，你需要回滚代码，却发现海量的 commit 需要一条条来看。
遵循项目规范才能提高团队协作效率，而不是随心所欲。

 

2.在使用git作为源代码管理工具 可以将 多个commit 需要合并为一个完整的commit提交。

在一个基本的迭代周期里，你会有很多次commit，有跟配置文件相关的，有跟代码相关的，甚至有跟下次发布fixbug相关的。这些都是你在完成本地开发的时候一个变化记录而已。但是当你需要将你的迭代项目作为一次发布提交时就需要整合所有之前提交的那些很零碎的commit。

多个commit合并为一个commit，这样如果这个需求出现什么严重问题，只需要立即将这一个内容进行回滚即可(默认已经配置zsh）

glol/glola/git log查找需要rebase的起点commit
glol/glola/git log

可以得到一个分支树，这样我们可以得到对应起点的commit的hash值或者知道前面有多少个commit，这对我们下一步rebase至关重要，glol, glola和git log三个使用其中一个即可

• Glol: 获取本地当前分支树
• Glola：获取本地全部的分支树（包括不在的部分）
• Git log：查看日志

Git rebase -i合并commit
git rebase -i commit-id :合并commit-id之前所有的commit，不包括commit-id
git rebase -i HEAD~3：将最近3次的提交合并

可以得到下面的vi

假如最后一个是我们需要的，我们需要把剩下的内容前面的指令改为s，也就是把剩下的部分挤压到指定的commit中，达到合并为一个的目的
当然合并的过程可能会有冲突，我们需要解决，但是解决完需要做的不是commit，而是

git rebase --continue

如果合并过程中，改变主意不想继续下去了，可以终止rebase的进程

git rebase --abort

 

后面只要根据提示正常走完即可
推到远程分支
这时候我们如果再进行第一步使用glol将分支树打开可以看到我们之前的分支已经不见了，合并为一个分支了，在推到远程之前我们需要先rebase master分支来保证master分支这时候别的同学提交的代码我们也一并弄进来了
git rebase origin/master

这时候我们需要推到远程，因为现在我们的分支树和远程的是不一样的，直接git push肯定是不可以的，shell控制台会提示你git pull来保证分支树的一致

$ git push origin PORT-3281:PORT-3281
To ssh://stashdirect.prometheanjira.com:7999/pa/portal-functional-tests.git
 ! [rejected]        PORT-3281 -> PORT-3281 (non-fast-forward)
error: failed to push some refs to 'ssh://stashdirect.prometheanjira.com:7999/pa/portal-functional-tests.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

 

绝对不要使用git pull！！！
因为git pull本身的目的是为了保证本地和远程的基层分枝树一致，在一致的基础上插上新的节点，我们现在已经把几个节点归成了一个大节点，如果git pull，再推上去，我们只是新增一个大节点，并没有实现把多个老的节点合并为一个大节点的目的

$ git push origin PORT-3281 -f

 

可以使用强推把远程的节点树和我们当前的保持一致，这样再打开远程的记录看一下，就会发现我们预期的目的就已经实现了

 

 

二、rebase和merge的区别

这里加一个小插曲，既然用到了rebase，我们就应该了解rebase的原理到底是什么，它到底对分枝树做了什么，有一篇文章写的很好，这里截图展示一下

 

三、git pull --rebase和$ git pull区别

是git fetch + git merge FETCH_HEAD的缩写，所以默认情况下，git pull就是先fetch,然后执行merge操作，如果加-rebase参数，就是使用git rebase代替git merge 。更新本地仓库

 

参考文章：https://www.jianshu.com/p/129e721adc6e