merge 更常用在合併他人新增的功能（把 source 新增的 commit 插到 target 後頭）
rebase 因爲會影響到 target branch，所以比較適合：

• 整理 commit 順序、移除 commit
• 如果我從 develop 分出一個 branch feat/xxx，然後我在 feat/xxx 提交了幾個 commit，等到我要提出 PR 時發現 develop 有異動，這時候就能使用 git rebase develop 將我的這些改動以最新的 develop 為基底長上去。

讓我們先看看這MERGE和REBASE之間的區別

(參考: Atlassian官網)

初始狀態

• GIT提交歷史
  

• Main branch = 發布版本, 當有新功能要添加到項目時, 會分支出新Feature branch

• Main branch通常被protected避免未經授權的merge, rebase, 甚至delete

• Feature branch = 由於新功能開發而創建, creators通常將擁有完全權限

MERGE

• GIT提交歷史
  

• Merge會將source code change從一個分支合併到另一個分支

• Merge會將history保存, 任何看到GIT history的人都可以看到你merge的操作

• 將history保存似乎是優勢, 但也可能會造成麻煩因為它會導致麵條式代碼

• 例子: 如果經常執行不必要的merge, 你可能在commit history中畫了一朵花出來

REBASE

• GIT提交歷史
  

• Rebase會將source code change從一個分支合併到另一個分支 (和merge一樣)

• Rebase不會將history保存, 任何看到GIT history的人永遠不知道你做了這次rebase

• 由於上述特性(不是缺點)，你的GIT history會更乾淨

• Rebase是破壞性操作, 就像從地球搬到火星一樣, 原本生活在地球上的其他人都應該搬到火星繼續在那工作, 否則他們將無法GIT push

我自己的看法

• 如果您在Feature branch中, 則應經常使用Main branch進行rebase, 以確保您正在使用最新Main branch源代碼開發

• 因為您正在Feature branch開發, 屬於您自己的分支. 在不通知其他人的情況下更改歷史記錄（甚至刪除分支）將不會影響其他人

• 當然最好的做法是通知與您一起在Feature branch上工作的每個人你已經搬到火星了

• 如果Feature branch已經完成開發並且準備合併到Main branch, 您應該使用merge, 以便可以在GIT history記錄此事件

• 當然最好的做法是合併請求(merge request), 允許經理或主管在合併之前查看源代碼