兩個git repo合併在一起

之前接到一個修改需求，原本以為只是單一專案，做到一半才知道還要把另一份 Git repo 的內容合進來。這種情況很容易腦袋一熱就直接 copy 檔案，但如果你還想保留歷史、看得懂誰改了什麼，還是應該用 Git 的方式處理。

先想清楚你要的是哪一種合併

兩個 repo 合併在一起，其實可能是不同需求：

1. 只想拿幾個 commit 過來。
2. 想把對方整段歷史一起保留。
3. 只是想把對方目前檔案內容搬進來。

如果需求不同，做法也不同，不一定都該直接 merge。

最基本的做法

如果是要把另一個 repo 接進來看，再決定怎麼整合，通常會先：

1. git remote add other <repo-url>
2. git fetch other
3. git checkout -b other-branch other/master
4. 再評估要 merge、cherry-pick，還是手動整理

這樣至少可以先把對方歷史帶進本地，不會一開始就亂掉。

直接 merge 會遇到什麼

如果兩邊本來就是不同根的專案，直接 merge 常見會遇到：

1. 目錄結構完全不同。
2. 同名檔案內容完全不同。
3. 衝突很多，解起來非常痛苦。
4. 合併後歷史很難閱讀。

所以我後來也覺得，這招雖然理論上能做，但不一定是最適合的。

我後來的想法

事後想想，如果任務本質上是「以對方 repo 為主，把我做的修改接回去」，那比較務實的方式可能是：

1. 直接 clone 對方 repo。
2. 在對方 repo 上重做或補上我的修改。
3. 讓 commit 歷史維持在同一條脈絡上。

這樣有時反而比硬把兩個 repo merge 成一坨更乾淨。

什麼時候用 cherry-pick

如果你真正需要的只是少數幾個 commit，而不是整個 repo 歷史，cherry-pick 往往更實際。尤其當另一邊還有大量不相關檔案時，直接挑 commit 過來會清楚很多。

小提醒

1. 合併前先確保目前工作目錄乾淨。
2. 先看對方 repo 的預設分支不一定還叫 master。
3. 如果是完全不同專案，先規劃要不要放進子目錄，避免根目錄直接互撞。
4. 不要把「Git 能 merge」誤解成「業務上就適合 merge」。

參考

处理合并冲突
git - 为什么要先commit，然后pull，最后再push？而不是commit然后直接push？ - SegmentFault 思否
Is it possible to cherry-pick a commit from another git repository? - Stack Overflow