Connect a private Git repo — and get two-way Obsidian sync

Your notes are the most valuable thing you make in a research tool. So the most important question to ask of any tool is not "how good is its editor?" but "how easily do my notes get out — and stay mine?" ScholarThread's answer is Git sync: connect a private GitHub or GitLab repository and your notes live there too, as plain Markdown files, in a place you control.

This post explains why that matters more than it might first appear, then walks through connecting a repo and — the part people love — wiring up a genuine two-way sync with Obsidian.

Why Git, of all things?

Git is a version-control system built for source code, which makes it a slightly surprising home for research notes. But that is exactly why it works so well. Think of a Git repository as a neutral, agnostic middle-man that sits between your tools and answers to none of them.

• It is vendor-neutral. A GitHub or GitLab repo does not care that ScholarThread wrote to it, or that Obsidian reads from it, or that in three years you use something else entirely. It is just a folder of Markdown files with a history. No tool owns it; you do.
• It is portable and durable. Markdown in Git is about as future-proof as digital text gets. You can clone it to any machine, read it in any editor, grep it, back it up, and open it in a decade. There is no proprietary database to export from and no format to be trapped in.
• It is versioned by design. Every sync is a commit. You get a complete, timestamped history of how your notes evolved, and you can roll back a mistake. This is the thing purpose-built note apps bolt on awkwardly; Git does it as its whole reason to exist.
• It works with hosting you already trust. GitHub, GitLab, Gitea, Codeberg, a self-hosted server — if it speaks HTTPS Git, ScholarThread can sync to it. Your notes sit under your account, your privacy settings, your organisation's rules.

The payoff of an agnostic middle-man is that it lets other tools plug in without any of them having to integrate directly. ScholarThread does not need to know about Obsidian, and Obsidian does not need to know about ScholarThread — they just both talk to the same Git repo. That is how you get two-way sync between two apps that have never heard of each other.

Connecting a private repository

The full click-by-click steps — including exactly which token scopes to set — live in the FAQ:

Git sync: how do I connect a private GitHub / GitLab repository?

The shape of it is short:

1. Create a private repository on your Git host (an empty repo is fine — call it something like notes-vault).
2. Create a fine-grained personal access token (PAT) scoped to that one repository, with contents read + write (read-only if you only want to import).
3. In ScholarThread, open Settings → Git sync, paste the HTTPS clone URL and the token, choose a direction (export only, import only, or bidirectional), and connect.

A note on security: your token is envelope-encrypted with AWS KMS before it is stored, and it is never handed back to your browser after you submit it — the connected view shows only a masked placeholder. Scoping the PAT to a single repository keeps the blast radius small, which is good practice regardless.

Once connected, each sync becomes a commit in your repo. Turn on auto-sync if you want it to run on a schedule, or leave it manual and hit Sync now when you please.

The good part: two-way sync with Obsidian

Because your notes are now Markdown in a Git repo, you can point Obsidian at the same repository and edit them there too. The bridge is the community Obsidian Git plugin, which commits and pulls on your behalf — turning an Obsidian vault into a Git working copy.

The topology is simple: ScholarThread ⇄ Git repo (GitHub / GitLab) ⇄ Obsidian. Neither app talks to the other. The repository in the middle is the shared source of truth, and each side pushes its changes up and pulls the other side's changes down.

To set it up on the Obsidian side:

1. Clone the same repository to a local folder and open it as an Obsidian vault (or install Obsidian Git into an existing vault whose folder you have turned into a clone of the repo).
2. In Obsidian, install the Obsidian Git community plugin from Settings → Community plugins.
3. Configure it to pull on startup and to commit and push on an interval (for example, every few minutes, or on save). This is what makes the sync feel automatic rather than manual.
4. Authenticate the clone to your host — the same fine-grained PAT works here too, used as the HTTPS credential for the vault's clone.

Now the loop is closed. Write a note in ScholarThread, it syncs to the repo; Obsidian Git pulls it into your vault. Edit that note in Obsidian, it commits and pushes; ScholarThread pulls it back on its next sync. The same works in reverse for notes that start life in Obsidian.

Living with conflicts

Any two-way sync has to answer the question: what if the same note changed in both places between syncs? ScholarThread's Git sync resolves conflicts by last-updated timestamp — the most recent edit wins. In everyday use conflicts are rare, because you are usually working in one tool at a time. But a couple of habits keep it smooth:

• Sync before you switch tools. A quick sync when you move from ScholarThread to Obsidian (and back) keeps both sides current and all but eliminates overlap.
• Set Obsidian Git to pull on startup. Starting each Obsidian session with the latest from the repo means you are editing the current version, not an old one.
• Do not hand-edit the same note in both apps at the same moment. That is the one scenario where last-writer-wins can drop a change — and it is easy to avoid.

The bigger point

The reason to reach for Git here is not that it is clever. It is that it makes your notes independent of any single tool — including ours. A private repo is a durable, versioned, vendor-neutral home you fully own, and it happens to make ScholarThread and Obsidian work together for free. If you ever move on, your notes come with you, in the plainest, most portable form there is.

When you are ready, the exact setup steps are in the Git sync FAQ.