Obsidian / Git競合の復元例
原文を残して、内容を選ぶObsidianのGit競合を直す
原文を残し、比べて保存する
本文に競合マーカーが出たら、手元にある両方の原文を別々に残し、どの内容を採用するか確認します。この小さな演習では、二つの確認項目を選んでObsidianで保存し、ローカルGitのmerge完了と再表示まで確かめました。
確認する順番は、原文・選ぶ内容・保存結果
今回の対象は、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の入力・配送は試していません。
本サイトは株式会社ユリカが運営し、独立アプリ「Obsidian連携シンプルメモ」を紹介しています。Obsidian公式による記事ではありません。