Obsidian Gitの使い方｜履歴の保存と復元

Obsidian Gitを始めるなら、デスクトップの練習用Vaultで、変更の確認・履歴への記録・1枚のノートの復元まで試すところを最初の目標にしましょう。GitHubへの送信や自動同期は、その後に必要性を判断できます。

この記事では、プラグインの導入と機能は開発者の公式資料を基に説明します。編集部が実行したのは、合成ノートを使ったGitのコマンド操作です。ObsidianアプリやGitプラグインの画面操作、外部への送信、スマートフォンでの動作は実演していません。確認日は2026年10月27日、実証環境はmacOS上のGit 2.50.1です。

Obsidian Gitで残せる履歴と前提

Gitは、ファイルのある時点の内容を「コミット」という単位で記録する仕組みです。Obsidian Gitは、その操作をObsidianから扱うためのコミュニティプラグインです。Git本体、プラグイン、GitHubなどの外部保管先は、それぞれ役割が異なります。

開発者の開始手順には、手元で新しいリポジトリを作る方法と、既存のリモートから複製する方法があります。手元で履歴を残すところから始められるので、最初から外部サービスへの登録や接続まで一度に進める必要はありません。

ただし、同じ端末の中にしか履歴がなければ、その端末や保存媒体を失ったときに一緒に失う可能性があります。履歴を残すこと、複数端末の内容を同期すること、別の場所へコピーを保管することを分けて考えます。Obsidian公式のバックアップ案内でも、同期とバックアップを区別しています。

今回向いているのは、文章の修正を後から比較したい人や、誤って変えたノートを戻せるようにしたい人です。スマートフォンとの同期だけを簡単に設定したい人は、同期方式を先に検討したほうが目的に合います。

Obsidian Gitを始める前の準備

練習用のVaultとGit本体を用意する

最初は、実際の業務資料が入っていない練習用Vaultを一つ用意します。ノート名、本文、添付ファイルも架空のものにすると、設定を試す際に共有範囲を気にせず結果を比べられます。すでにGit管理されているVaultやリモートがある場合は、その構成を確認し、新規作成の手順を重ねないようにします。

デスクトップではGit本体の準備も必要です。プラグインの導入資料はOS別に条件を案内しており、WindowsではGitHub Desktopだけで準備が完了するわけではないと説明しています。MacやLinuxでも、Obsidianのインストール方法を含めて該当する項目を確認してください。

ターミナルでgit --versionを実行すると、使えるGitの版を確認できます。編集部の検証ではgit version 2.50.1 (Apple Git-155)でした。この出力はGit本体が動いた証拠であり、Obsidianから同じGitを扱えることまで確認した結果ではありません。

公式資料に沿ってプラグインを導入する

開発者の案内では、Obsidianの設定からコミュニティプラグインの検索画面を開き、「Git」を探してインストール・有効化します。似た名前だけで選ばず、開発元の資料と対応するものか確かめます。会社で使う場合は、コミュニティプラグインの導入が認められているかも先に確認します。

新しい練習用Vaultでは、開始手順にあるInitialize a new repoがローカルリポジトリの作成入口です。既存のリモートを使う場合は、同じ資料の複製手順が別にあります。この記事の練習は手元の履歴だけに絞り、外部の保管先は登録しません。

初回の記録前に、履歴へ入れるファイルを決めることも必要です。設定ファイルまで残すのか、プラグインの設定や個人用メモを除くのかを書き出します。詳しい除外の確認方法は後述します。プラグイン自体の選び方は、Obsidianのおすすめプラグインと選定の考え方も参考にしてください。

Obsidian Gitで変更を記録する

編集したファイルを保存することと、Gitの履歴に残すことは別です。コミットでは、その時点で記録する変更を選びます。何を選んだかが分からないまま自動化すると、戻したい版が見つからなかったり、残すつもりのない情報まで記録したりする原因になります。

開発者の機能説明によると、Source Control Viewで変更ファイルと差分を確認し、ファイル単位でステージできます。ステージとは、次のコミットへ入れる対象を選ぶことです。History Viewではコミットと変更されたファイル、その差分を確認できます。これらは公式資料の説明で、今回の編集部による画面実演ではありません。

1. 最初の状態を記録する。 ノートを保存し、対象ファイルを確認してコミットします。
2. 一つの意味のある変更を加える。 例えば、確認前のメモに原典を読んだ結果を書き足します。
3. 差分を読む。 予定した変更だけか、余計なファイルが混ざっていないか確かめます。
4. 対象を選んでコミットする。 後で区別できるよう、変更の内容が分かるメッセージを付けます。
5. 履歴から見直す。 記録した版に、意図したノートと差分があることを確認します。

編集部は合成の調査メモを使い、「状態: 確認前」「次の行動: 原典を読む」という初期版をコミットしました。その後、「状態: 確認済み」「次の行動: 根拠を添えて引き継ぐ」へ変更し、もう一度コミットしています。Gitの差分出力には、この2行の変更が現れました。

検証ではgit add -- notes/research.mdのように対象を指定しました。すべての変更をまとめて記録する前に、一つのノートで記録単位を確かめるためです。実際の業務でも、会議メモの修正とプラグイン設定の変更を分けて記録すれば、何のための変更だったかを追いやすくなります。これは編集部の運用上の提案であり、Gitが要求する固定ルールではありません。

自動コミット等の機能を使う場合も、まず手動で対象と結果を確認します。「設定したから残っている」ではなく、必要な版が履歴に存在するところまで見ることが大切です。

Gitの履歴から1枚のノートを戻す

戻したいときは、最初に「どのノートを、どの版にするのか」を決めます。Vault全体を一度に巻き戻す必要があるとは限りません。現在の内容を別ファイルへ控え、未記録の変更も確認してから、練習用の1枚で試します。

今回の検証では、初期コミットを指定してnotes/research.mdだけを復元しました。Git公式のgit restoreの説明では、指定した元の内容へ対象パスを合わせる操作とされています。現在の対象ファイルが書き換わるため、残したい変更を先に保全します。

作業場所と戻したい版を先に確認する

以下は、練習用VaultのGitリポジトリのルートで実行します。ルートは、そのリポジトリの一番上のフォルダです。ターミナルの作業場所を練習用Vaultへ移してから、次を1行ずつ確認してください。実際の業務用Vaultでは試しません。

git rev-parse --show-toplevel
git status --short
git log --oneline -- notes/research.md

1行目はリポジトリのルートの確認です。表示された場所が練習用Vaultと一致しなければ、そこで止めて作業場所を見直します。2行目は現在の変更の確認です。残したい未記録の変更は先に控えを作るかコミットします。3行目は対象ノートのコミット履歴を短いIDと説明で表示します。ここで初期版などの候補を選びます。

次に、そのIDを使って過去のファイル内容を表示し、戻したい本文があるか読みます。次の<確認したコミットID>は、かっこごと実際のIDに置き換えてください。パスはリポジトリのルートからの場所です。

git show <確認したコミットID>:notes/research.md

ここまでは復元を実行せず、場所・現在の変更・履歴・復元元の本文を確認する手順です。ファイルがないというエラーが出た場合や、欲しい本文でなかった場合は復元へ進まず、IDとパスを選び直します。対象を確認できたら、同じIDとパスで次を実行します。

git restore --source=<確認したコミットID> -- notes/research.md

<確認したコミットID>には、自分の練習用リポジトリで内容を確かめた版を指定します。例のパスも、確認した対象に置き換えます。過去の版に対象ファイルが存在することを先に確かめてください。元に存在しない追跡対象は、復元操作で削除される場合があります。

復元後は本文が「確認前」へ戻り、ファイル内容から計算したSHA256も初期版と一致しました。SHA256は内容の一致を確認するための値です。変更後の値とは異なっていました。これにより、この合成ファイルでは指定した版の内容へ戻ったことを確かめられました。

実際の確認では、値だけで終わらせず、復元した本文を開いて読むことも必要です。欲しかった説明が戻っているか、残すつもりだった追記がなくなっていないかを見ます。今回の実証はコマンド操作の範囲なので、Obsidian内での再表示やプラグイン画面からの復元手順は別途確認が必要です。

なお、ノートの内容を戻したことと、過去のコミットを消したことは同じではありません。検証では復元結果を新しいコミットとして記録し、変更と復元の経緯を残しました。履歴の仕組みを確かめる最初の練習では、経緯を消さず、どこで何をしたかをたどれる形が扱いやすくなります。

Obsidian Gitの除外と運用上の注意

除外は最初の記録前に確かめる

.gitignoreは、履歴の対象にしないファイルを指定するためのファイルです。Gitプラグインの運用上の工夫には、Obsidianの設定、プラグイン設定、キャッシュなどを除く例があります。すべてを一律に除外するのではなく、何を復元したいかと、どこへ保存してよいかを基準に選びます。

編集部の合成環境では、.env、private/、ダミープラグインの設定ファイルを除外対象にしました。git check-ignoreの結果から、まだ追跡していない指定ファイルが除外されることを確認しています。これらは試験用に作ったファイル名であり、実際の秘密値は入れていません。

すでに記録したファイルは、後から.gitignoreへ書くだけでは追跡が外れません。これはGit公式の仕様です。検証でも、先に追跡した合成ファイルを除外規則へ追加した後、その内容を変えると差分が表示されました。除外設定を作っただけで、過去の履歴から情報が消えたと判断しないでください。

会社の資料を扱う場合は、本文だけでなく、添付や設定にも保存範囲の判断が必要です。個人の履歴管理から複数人の運用へ広げるときは、Obsidianを会社で使う際の共有方法と導入条件を先に整理すると、Gitへ任せる範囲も決めやすくなります。

外部保管とモバイルは別の工程にする

外部へ送る段階では、接続先、送るファイル、公開範囲、認証方法の確認が加わります。今回の合成リポジトリにはリモートを設定しておらず、送信も受信もしていません。ローカルで履歴を戻せた結果を、外部バックアップや複数人の同時編集まで検証済みと読み替えることはできません。

また、Gitプラグインの開始資料では、モバイルの実装は非常に不安定だと説明されています。デスクトップで成功した操作を、そのままiPhoneやAndroidへ勧めないことが大切です。スマートフォンを含む同期が主目的なら、対応する同期方式と端末固有の条件を調べるところから始めます。

まずは合成ノート1枚で「変更を読める」「履歴に残せる」「指定した版へ戻せる」を確認しましょう。その後、履歴の対象、別場所への保管、誰が変更を確認するかを決めて業務へ広げます。ここまで分けると、便利な自動化を追加する際にも、守るべき記録と確認の責任が明確になります。

履歴管理を社内のナレッジ活用へつなげたい場合は、PLaiのAI社員導入支援で、資料の保存範囲と確認担当を含めた運用を相談できます。

● 代表・市岡と話す、30分の個別面談

AI活用の「何から？」を、
30分で解決。

御社の仕事を伺い、AIに任せる業務と
最初に試すことを、一緒に決めます。

• 01AIに任せたい仕事を整理
• 02自社に合う始め方を具体化
• 03明日からの一歩を決める

30分の面談を申し込む↗

オンラインで30分AI社員導入支援について →

記事を読む、その先へ。
次は、御社の話を聞かせてください。