git rebase -i 后強制推到遠端（一）

本文轉載自查看原文 2022-02-22 20:49 2081 Git

一、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.