單元 7：合併與衝突處理

conflict 不是 Git 壞掉，而是 Git 不替人做決定

如果 main 沒有新的 commit，merge 可以直接 Fast-forward；如果兩條 branch 都前進，Git 需要整合兩邊的變更，通常會建立雙親 merge commit。

兩邊修改同一段內容時，Git 不知道哪個才是正確答案，因此留下 conflict 標記：

&lt;&lt;&lt;&lt;&lt;&lt;&lt; main
main 的內容
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
feature 的內容
&gt;&gt;&gt;&gt;&gt;&gt;&gt; feature/login

標準流程是：閱讀兩邊 → 編輯成真正要保留的結果 → git add <path> 標記已解決 → git commit 完成 merge。若判斷不該繼續，可用 git merge --abort 回到開始前。

不要看到 conflict 就只選 ours 或 theirs。真正答案可能是合併兩邊，或重新寫成第三種內容。

A conflict does not mean Git is broken; it means Git will not decide for you

If main has no new commits, a merge can fast-forward. If both branches moved forward, Git must combine their changes and usually creates a two-parent merge commit.

When both sides edit the same lines, Git cannot know the correct answer and leaves conflict markers:

&lt;&lt;&lt;&lt;&lt;&lt;&lt; main
content from main
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
content from feature
&gt;&gt;&gt;&gt;&gt;&gt;&gt; feature/login

The standard flow is: read both sides → edit the result you truly want → run git add <path> to mark it resolved → run git commit to finish the merge. If you should not continue, git merge --abort returns to the starting point.

Do not automatically choose ours or theirs. The right answer may combine both sides or be a third version written from scratch.

離開前，確認你能用自己的話說明Before you leave, explain it in your own words

這些指令改變 Git 的哪一個區域？

Git 樹上的 branch 與 HEAD 移到哪裡？

失敗時 repository 是否保持原狀？

真實專案操作前，應先查看什麼？

Which Git area does this command change?

Where do the branch and HEAD move in the Git tree?

Does the repository stay unchanged when the command fails?

What should you check before operating on a real project?

合併與衝突處理Merge branches and resolve conflicts

conflict 不是 Git 壞掉，而是 Git 不替人做決定

A conflict does not mean Git is broken; it means Git will not decide for you

在安全模擬器裡親手操作

正在編輯的檔案

下一版準備內容

電腦裡的版本

GitHub 示意狀態

虛擬檔案編輯器

commit 與 branch

離開前，確認你能用自己的話說明Before you leave, explain it in your own words