確認的順序是原文、選擇內容、儲存結果
這次的物件是，在Git的merge中相同的Markdown正文中加入競爭標記的情況。 用本地Git的兩個分支編輯了作者製作的一個筆記，確認了實際的merge失敗、原文的比較、手動修正。 不是在多個終端上同步的結果。
- 手動保留兩份原文準備能夠區分兩邊內容的副本
- 比較差異確認不同的一行和共同部分
- 決定採用的內容這個例子將相容的兩個專案分成不同的行
- 編輯並儲存確認正文和Git側的merge完成
- 重新顯示並確認核對所選內容和儲存Markdown
這個順序是整理這次演習的圖。 不是顯示自動恢復和防止消失的保證、同步服務的每個操作步驟的圖。
首先，確認自己的競爭形式
在這個例子中，Git的merge在結束程式碼1停止，作業メモ.md變成了UU。 Git的index有共同的原版和兩個編輯版，筆記本正文有<<<<<<< HEAD、=======、>>>>>>> draft-b。
在自己的環境中出現別名的衝突檔案或履歷畫面時，請根據同步方式進行確認。 查詢方式的入口是Obsidian的同步方法指南。 這篇報道的Git結果，不能換成Obsidian Sync和iCloud的行為。
本次在競爭狀態下儲存的正文如下。 刊登了包括標記在內的真實檔案的全文。
# 作業メモ
ローカルの競合を確かめるために著者が作った練習用ノートです。
## 次の確認
<<<<<<< HEAD
- 確認する項目: 見出しの順番を確認する。
=======
- 確認する項目: 内部リンクの保存先を確認する。
>>>>>>> draft-b
1。 將手邊的兩份原文分別留下
在開始編輯之前，將手邊的各個版本，以知道原版本的名字分別儲存。 如果手邊只有其中一個的話，請不要把另一個也儲存下來，請確認Git的狀態和使用方式的履歷。 從各服務的履歷中恢復的操作，這次沒有嘗試。
在修復衝突之前確認恢復到以前的正文的準備時，也請參考Git・File Recovery・保管庫外副本的恢復例。
在這個練習中，在merge之前，作者手動保留了方案A、方案B的副本。 為了比較，在保管庫裡也放了原文の控え/案A.md和原文の控え/案B.md開啟了。 這些不是同步工具自動生成的conflicted copy。
| 版 | 變化的確認專案 | 共同部分 |
|---|---|---|
| 方案A | 確認標題的順序 | 標題、練習用筆記的說明、下一個確認的標題 |
| 方案B | 確認內部連結的儲存地址 | 和方案A一樣 |
不是隻根據更新時間來判斷，而是閱讀文章並確認必要的資訊。 因為這次的兩個作為不同的確認專案並存，所以作者決定按照A・B的順序兩行都採用。 實際文章矛盾或重複時，需要根據其內容進行選擇。
2。 用Obsidian編輯決定的內容，確認儲存
在實際的Obsidian編輯器中開啟作業メモ.md，輸入了選定的正文。 在這個例子中，我們保留了共同的說明，將兩個專案分開行，並刪除了衝突標記。 等待自動儲存，確認在真實檔案中儲存了以下全文。
# 作業メモ
ローカルの競合を確かめるために著者が作った練習用ノートです。
## 次の確認
- 確認する項目: 見出しの順番を確認する。
- 確認する項目: 内部リンクの保存先を確認する。
在自己的筆記中，除了記號筆消失之外，重新閱讀選擇的內容、行的順序、決定留下的共同部分。 總結本文的判斷和在Git方面完成merge的操作是分開確認的。
3。 確認Git的未解決狀態，完成merge
在這個練習中，用Obsidian儲存正文後，Git的狀態也是UU。 之後，只明確說明目標筆記git add，在本地製作了merge commit。 兩個原來的commit作為父存在，git ls-files -u是空的，Git的狀態變成了clean。
接下來是在本地Git上確認目標檔案的命令示例。 確認實際的筆記名和儲存庫後使用。 在git add之前，請確認採用的正文和其他工作狀態。
git status --short -- "作業メモ.md"
git ls-files -u -- "作業メモ.md"
# 採用する本文を確認した後、対象ノートをstageする
git add -- "作業メモ.md"
git commit
# merge完了後の未解決indexと状態を確認する
git ls-files -u
git status --shortGit操作是用本地命令進行的。 沒有使用Obsidian Git外掛，也沒有確認remote、push/pull、其他終端的反映。 狀態是clean，也不能證明備份的耐用性和所有終端的配送。
4。 重新開啟筆記本，閱讀選擇的內容
建立 merge commit 後，我們從實際的檔案瀏覽器重新開啟 作業メモ.md。閱讀檢視顯示了兩項內容，沒有衝突標記。重新顯示前後的 Markdown 具有相同的 SHA256，原始 A、B 副本以及各次 commit 的正文也都保留了。
這個結果是透過這個作者製作的筆記和一次本地恢復確認的。 並不是所有衝突、所有同步方式都不會丟失資訊的結果。
下載原文、競爭狀態、儲存結果
四個Markdown是原文A/B、競爭狀態、最終儲存結果的原件。 分發名是區分狀態的別名，實際的工作筆記名是作業メモ.md。 在比較內容的練習中，請以不同的名字儲存，在不覆蓋自己筆記本的同名檔案的地方進行確認。
| 狀態 | 分發檔案 |
|---|---|
| 原文A | original-a.md |
| 原文B | original-b.md |
| 競爭狀態 | conflicted-note.md |
| 儲存結果 | resolved-note.md |
分發檔案的讀者端的匯入、恢復操作，不包括在這次的實際應用程式驗證中。
常見問題
本文的衝突標記和conflicted copy是一樣的嗎？
兩個句子都留下就能解決嗎？
刪除並儲存衝突標記後，Git的merge也會完成嗎？
這個步驟在Obsidian Sync和iCloud上也驗證過了嗎？
驗證環境和確認範圍
- 實際應用程式：2026年9月30日的Linux版Obsidian 1.13.7。 作者製作的日語筆記，一個離線本地Git儲存庫，沒有社群外掛。
- 實際的Git結果：merge失敗，UU，未解決index的三個階段，衝突標記，明確物件的stage和擁有兩個父的merge commit，未解決index為空，狀態clean。
- 實GUI：確認原文A、衝突筆記、儲存後筆記的實檔案瀏覽器操作、實編輯器中選擇的正文的輸入和儲存、讀取檢視、筆記的重新顯示。
- 輔助說明：合併後的筆記和原文副本是直接作為檔案準備的。左右分屏、顯示 B、側邊欄、設定視窗以及狀態讀取使用了應用 API。Git 操作在本地 shell 中完成。
- 未驗證：自動conflicted-copy生成、Obsidian Sync、iCloud、其他同步服務、remote、兩臺同時編輯、iOS/Android/Mac、SimpleMemo配送、長期備份、速度、生產力、流入效果。
原始影象是未經加工的實際Obsidian的畫面，Markdown是實際檔案的原件。 驗證記錄和原件的對應中記載了實際操作、輔助、極限。
確認方式的入口
同步方法的比較指南是為了選擇方式的現有報道。 這個頁面作為比較原文復原的例子，將主題分開。 在這篇報道中沒有嘗試SimpleMemo的輸入和配送。
本網站由YURIKA, K.K.運營，介紹獨立應用程式“SimpleMemo”。 不是Obsidian官方的報道。