【問題】假設你在txt_main_2分支修改提交，有一個commit點，然後push到遠端，準備提交到master分支，發現有3個commit點。
【原因】之所以出現多個commit點是因爲，在上一次你的txt_main_1分支同步master分支的時候，直接從mster分支merge到txt_main_1，導致這次提交的時候把有些原來主線的commit點識別成爲你當前分支txt_main_1的最新提交點。
【解決方法】
在txt_main_1分支 ：
git rebase br_dev_main
git push -f
然後再去提MR就正常了。
git rebase VS git merge
git rebase 和 git merge是git合併分支的兩種方式，然而他們卻採用了不同的工作方式，以下面的一個工作場景說明其區別：
場景：
下圖所示：當feature分支有新的需求提交，同時，master 分支也有修改。
這時，如果要將master 上新的提交合併到你的feature分支上，我們有兩種選擇：merging or rebasing
merge
執行以下命令：
git checkout feature
git merge master
或者執行：
git merge master feature
此時在feature上git 自動會產生一個新的commit(merge commit)
look like this：
marge 特點：自動創建一個新的commit
當合並時遇到衝突，修改後重新commit即可
優點：將commit的實際情況進行記錄，便於以後查看
缺點：由於每次merge會自動產生一個merge commit，所以在使用一些git 的GUI tools，如果commit頻繁，這樣會使得feature分支很雜亂，這時可以考慮使用rebase來進行合併處理。
rebase
本質是變基，即找公共祖先
執行以下命令：
git checkout feature
git rebase master
look like this:
rebase 特點：將commit歷史進行合併
優點：項目歷史比較簡單，少了merge commit
缺點：當發生衝突時不容易定位問題，因爲re-write了history
合併時如果出現衝突需要按照如下步驟解決
修改衝突部分
git add
git rebase --continue
（如果第三步無效可以執行 git rebase --skip）
不要在git add 之後習慣性的執行 git commit命令
The Golden Rule of Rebasing rebase 的黃金法則
never use it on public branches(不要在公共分支上使用)
比如說如下場景：如圖所示
如果你rebase master 到你的feature分支：
rebase 將所有master的commit移動到你的feature 的頂端。問題是：其他人還在original master上開發，由於你使用了rebase移動了master，git 會認爲你的主分支的歷史與其他人的有分歧，會產生衝突。
所以在執行git rebase 之前 需要認真考慮，
會有其他人看這個分支麼？
if YES 不要採用這種帶有破壞性的修改commit 歷史的rebase命令
if NO ok，隨你便，可以使用rebase
結論：
想要乾淨的歷史，少了merge commit的線性歷史樹，選擇git rebase
而如果你想保留歷史記錄，並且想要避免重寫commit history的風險，使用git merge
—