rebase：
變基，意即改變分支的根基
變基會遇到兩種情況：
fast-forward: 這是一定不會發生衝突
non-fast-forward: 可能發生衝突, 可能不會
b想變基到a分支，在a分支上執行 git rebase b
衝突：
有衝突時，必須先手工處理衝突
之後git add .標記為處理完畢
再git rebase --contine完成變基
(跟git merge後的處理不一樣,在git add .處理完衝突後不是git commit)

git rebase操作實際上是將當前執行rebase分支的所有基於原分支提交點之後的commit打散成一個一個的patch，
並重新生成一個新的commit hash值，
再次基於原分支目前最新的commit點上進行提交，
並不根據兩個分支上實際的每次提交的時間點排序，
rebase完成後，
切到基分支進行合併另一個分支時也不會生成一個新的commit點，可以保持整個分支樹的完美線性

當我們開發一個功能時，可能會在本地有無數次commit，
而你實際上在你的master分支上只想顯示每一個功能測試完成後的一次完整提交記錄就好了，
其他的提交記錄並不想將來全部保留在你的master分支上，
那麼rebase將會是一個好的選擇，
他可以在rebase時將本地多次的commit合併成一個commit，還可以修改commit的描述等

前提假設：
假定，從 origin 拉出一個分支 mywork
現將 mywork 的部分提交合入 origin

命令操作(main_dev 合入 main)：
git add .
git commit -m "在 main_dev 上的修改"
git rebase main // 此步驟可省略？

git checkout main
git rebase main_dev // 此時，main_dev 變基到了main

git push

注意：上述分支提交時未 push，只有切換到主分支rebase完成後才push

簡單說相當於將 mywork 分支的所有提交點從最開始提交點移到了master的最新提交點進行合併
新生成的記錄就不是按提交的先後順序排序了

rebase注意事項
rebase過程中也會出現衝突
解決衝突後，使用git add新增，然後執行
git rebase - - continue
接下來Git會繼續應⽤用餘下的補丁
任何時候都可以通過如下命令終止rebase，分支會恢復到rebase開始前的狀態
git rebase - - abort

rebase最佳實踐
不要對master分支執⾏行rebase，否則會引起很多問題
一般來說，執行rebase的分支都是自己的本地分支，沒有推送到遠端版本庫

參考：https://blog.csdn.net/wzq6578702/article/details/76727740