MYR00
https://medium.freecodecamp.org/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785zhicheng Miya
大部分開發者都有遇到過該用 Merge 還是 Rebase 的問題，網絡上的各種相關介紹幾乎都認為：“不要使用 Rebase，因為它會產生各種問題”。這裡我將介紹 merge 和 rebase 的概念，為什麼你應該（或者不應該）使用它們，以及怎麼用。
Git Merge 和 Git Rebase 目的相同，它們都是把不同分支的提交合併到一起。雖然最終目的是一致的，但是其過程卻頗為不同。瞭解它們之間的區別之後，你會成為一個更出色的開發者。
Git 社區對這個問題有很大爭論，一些人堅持應該只用 rebase，另外一些人認為只用 merge，事實上兩種方式各有優勢。
Git Merge
對於使用版本控制系統的開發者來說，Merging 是常規操作。不管創建的分支是用來測試、修復 bug，還是別的什麼原因，可能都會需要把分支的提交 merging 到其它的分支上。具體來說，merging 就是把源分支的提交放到目標分支裡面。在這個過程裡，只有目標分支改變，而源分支保持原樣。
Merge Master->Featuer branch
優點
簡單易上手
保留了提交歷史和時間次序
保留了分支的結構
缺點
提交歷史被大量的 merge 提交汙染了
使用 git bisect 調試變得更困難了
怎樣做
使用 checkout 和 merge 命令把 master 分支 merge 到 feature 分支。
$ git checkout feature
$ git merge master
(or)
$ git merge master feature
這將會在 feature 分支上創建一個新的 “Merge 提交” 用來保留所有分支的記錄。
Git Rebase
Rebase 是合併兩個分支的另一種方式。Rebase 把所有的提交壓縮成一個 “patch”。然後把 patch 添加到目標分支裡。
和 merging 不同，rebasing 清除了歷史，因為它完全是從一個分支轉移到了另一個分支。在這個過程中，多餘的記錄被移除了。
Rebases 的提交從頂部按次序向下排列，而 merges 則自下而上。
Rebase feature branch into master
優點
把複雜的歷史變成優雅的提交線
操作單個提交變得很簡單（比如，reverting）
避免了龐大的倉庫、海量的分支以及煩人的 merge 提交
線性合併清除了中間的無用提交，對於 DevOps 團隊來說是個好消息
缺點
Rebase 後 feature 分支間的上下文模糊了
在團隊裡 rebasing 公共分支是高風險的事
工作變多了：feature 分支需要經常更新
Rebasing 到遠程分支需要 force push。最大的問題是人們經常已經 force push 了，才發現忘記了設置 git push 默認值。結果本地遠程所有同名的分支都進行了更新，清理起來很要命。
如果你 rebase 出錯並且很不幸重寫了歷史，很棘手，所以一定要明白操作的意義。
怎樣做
下面的命令把 feature 分支 rebase 到 master 分支上。
$ git checkout feature
$ git rebase master
它把整個 feature 分支的提交移動到了 master 分支上。通過給每個源(feature) 分支創建了一個 brand 來 re-writing 項目的歷史。
Interactive Rebasing
這個命令可以在移動 commit 前改變它們。這比普通的 rebase 更加強大，它提供了對分支提交歷史的完整控制。另外，在合併 feature 分支到 master 前，還可以用它來清理混亂的提交歷史。
$ git checkout feature
$ git rebase -i master
他會打開編輯器列出將要被移動的提交。
pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3
它清晰地展示了分支在 rebase 後的樣子。通過重新調整，提交歷史可以變成任何你想要的樣子。如，可以把 pick 換成 fixup , squash , edit 等命令。
選哪個
所以，哪個是最好的？有沒有專業的建議呢？很難明確告訴你該選哪一個，畢竟每個團隊的情況不同。但還是有章可循。
團隊在制定他們的 Git rebase vs. merge 策略時需要考慮很多問題。事實證明，工作流之間並無明顯的高下之分，一切都取決於團隊情況。
選擇更直白的 rebasing 還是歷史可塑性更強的 merging，要考慮團隊對 rebasing 的瞭解情況以及 Git 熟悉程度。
最後，決定使用 merging 還是 rebasing 還應該考慮到分支策略。團隊有必要制定一個合適的分支策略。
我的建議
隨著團隊增長，通過 merge 策略很難管理和追蹤到每個提交。為了提交歷史更清晰、更易於理解，使用 Rebase 是一個明智、高效的選擇。
下面是針對不同環境的建議，可以最大限度地發揮 Rebase 的優勢：
本地開發：如果你沒有和別人協同工作，你應該使用 rebasing 而不是 merging ，這樣歷史記錄會很清晰。如果你已經從倉庫拉取了你的個人 fork，並且不準備和別的開發者一起工作，在分支 push 前 rebase 也是可以的。
你的代碼準備好了被 review： 你創建了 pull request。別人正在 review 你的代碼，可能把它拉到了本地 review。如果這樣，你最好別 rebase 你的代碼。你應該創建一個 “rework” 提交來更新你的 feature 分支。它會讓 pull request 的可塑性更強，也能避免歷史突然丟失。
review 已經完成並且已經準備好了合併到目標分支。恭喜！你就要刪除你的 feature 分支了。由於別的開發者不需要拉取、合併這些更改，這是你清理記錄的好機會。你可以改寫記錄，摺疊原始提交、“pr rework” 提交和 "merge"提交，使之成為一整個清晰的提交。作為可選，你還可以給這些提交創建一個明確的 merge，這樣做實際上很有用。它會記錄 feature 併入master 的時間。
結論
希望這些解釋能讓你對 Git merge 和 Git rebase 更瞭解。Merge .vs. rebase 策略之爭永無止境。希望這篇文章可以幫助你掃清迷惑，找到一個適合自己的團隊的方向。
天使之光導師
也倒不一定會有問題。但是並不建議這樣使用git merge，因為很容易產生分叉和新的commit
雖然這樣操作非常簡單就能合併代碼，但是項目中都是合作開發，如果大家都這麼操作，那麼最後遠程主分支記錄結果就會變成
再看看使用git rebase和git merge的對比圖
但是並不是說不能使用git merge，而是需要了解了二者的區別以及適用場景採用合適的方式。
推薦一個玩遊戲學git的網站，非常有趣，玩完相信你會有一個新的認識。https://learngitbranching.js.org/
