GitJournal: a mobile Markdown notebook that commits to your own Git repo

The problem GitJournal solves: notes that outlive the app

Most note apps treat the database as the product. Your notes live in a proprietary store, exports are lossy, and the day the vendor changes direction you are left converting files. GitJournal inverts that. The README states the app is "focused on privacy and data portability" and that notes are stored "in a standardized Markdown + YAML header format (optional)" inside "a Git Repo of your choice - GitHub / Gitlab / Custom-provider".

The audience is narrow and specific. It is for people who already think in Markdown and already have a Git host, and who want the mobile editing experience to write into that repository rather than into a silo. The repository topics list journal, markdown, knowledge-management and memex, which matches the pitch: a personal knowledge base, not a team wiki.

The trade-off is immediate. A Git repository is a file store with a commit history, not a sync engine. Every device that edits the same note creates a commit, and reconciling those commits is the user's problem, not the app's. The README does not document a merge strategy, so anyone expecting the silent multi-device merging of a hosted notes service should read that silence as a warning.

How notes move from the editor to the repository

The repository layout shows a Flutter application with a shared Dart core and platform shells for android, ios, linux, macos and web. The Makefile reveals the internal boundaries: protobuf definitions live under protos/ and lib/analytics/, and the protos target regenerates Dart bindings for builders.proto, core.proto, markdown.proto and analytics.proto. That is the shape of the data flow. Notes are modelled as structured objects, serialized through generated Dart code, and written out as Markdown files with an optional YAML header.

Git itself is handled by a Dart package. The Makefile contains a bump_dart_git target that runs flutter packages upgrade dart_git, so the Git operations are not shelling out to a system binary; they run inside the app through that library. On mobile that matters, because there is no git executable to call.

The docs/ directory includes a git_hosts.md file referenced from the README as the list of supported providers, which is where the actual provider configuration lives. The README itself only names GitHub, GitLab and custom providers, and does not describe authentication flows or token handling. If you are evaluating this for an organisation, that documentation gap is the first thing to open.

Installing GitJournal and writing your first Git-backed note

The README does not give a build tutorial. It points to the Google Play listing for Android and the App Store listing for iOS, and the repository root contains BUILD.md for people building from source. Start with the store listings if you only want to use the app.

For a source build, the Makefile is the entry point. It prepends a project-local Flutter SDK to PATH, so the expected layout is a .flutter directory inside the checkout:

export PATH := $(DIR)/.flutter/bin/:$(PATH)

That line comes from the Makefile and assumes DIR is the repository root. Once the SDK is in place, the documented targets are the usual Flutter ones. Linting runs the analyzer, and the test suite runs through Flutter's test runner:

make lint
make test

Code generation is a separate step. The build_runner target regenerates generated Dart sources, and it is the target to run after touching protobuf definitions or build-time code:

make build_runner

Inside the app, the first real use is connecting a repository. The README says notes are stored in a Git repository of your choice, and points to docs/git_hosts.md for the provider list. The README does not give a step-by-step for adding a host, an access token or a repository path, so treat the in-app flow as the source of truth and expect to supply a token for a private repository. After the initial clone, a new note should appear in the working tree as a Markdown file, with a YAML header when that option is enabled.

Where a Git-backed notebook breaks down

The failure mode is conflict, and the project does not hide from it so much as leave it undocumented. Two devices editing the same note offline will produce divergent commits. Git can detect that divergence; it cannot decide which sentence you meant to keep. The README is silent on how GitJournal presents a merge conflict, whether it offers a resolution UI, or whether it simply refuses to push. Anyone whose workflow involves a phone and a laptop editing the same daily note should test that path before trusting it with a journal.

There is a second, quieter cost. Every note is a commit, and every commit is history. A repository used as a notebook accumulates a commit per edit unless the app batches, and the README does not describe batching behaviour. That is fine for a personal journal and awkward for anyone who later wants to publish or share the repository without exposing the edit trail.

The third limitation is scope. This is a Flutter app with a mobile-first framing, and the platform directories exist for Linux, macOS and web, but the README presents Android and iOS store links as the primary distribution. If you need a desktop-first editor with plugins, a command palette and a large extension ecosystem, GitJournal is not competing on that axis. It is competing on where your bytes live.

GitJournal versus Obsidian and Joplin: the difference is the sync layer

The two names that come up most in searches around GitJournal are Obsidian and Joplin, and the comparison is genuinely about architecture rather than features.

Obsidian is a local Markdown vault with a plugin ecosystem, and its own sync service is a paid product. The vault is a folder, not a repository. You can put that folder under Git yourself, but the app is not built around Git as its transport, and mobile Git clients are a separate problem. GitJournal makes the repository the primary object: cloning, committing and pushing are the app's job.

Joplin is closer in spirit on privacy and self-hosting, but its storage model is a database synchronized through a target such as WebDAV, Nextcloud or its own Joplin Server. Notes are exported to Markdown rather than being Markdown on disk as the canonical form. That is a real difference for anyone who wants to grep their notes from a terminal or feed them to a static site generator without an export step.

GitJournal's bet is that Git already solves versioning, backup and multi-host redundancy, so the app only has to solve editing and transport. That bet is correct for a certain kind of user and irrelevant for everyone else.

Maintenance, releases and the AGPL split

The last push to the default branch was on 2026-05-26, and the repository is not archived. The most recent GitHub release listed is v1.80.0 from 2021-09-15, labelled "First release on GitHub", which tells you that release tags on GitHub are not the distribution channel. The store listings are. If you are tracking versions, the changelog.yml file in the repository root is a better signal than the releases page.

The licence situation needs care because it is unusual. The README states that code contributed by Vishesh Handa is under AGPL-3.0, while code contributed by anyone else is under Apache License 2.0. The stated reason is to avoid a contributor licence agreement and to allow distribution on the Apple App Store, which the README says does not allow AGPL. There is a LICENSES/ directory and REUSE metadata in the repository, so per-file licence headers are the authoritative source for any given file. If you plan to ship a modified build, check the header on each file you touch rather than assuming a single licence covers the tree. That is a factual observation about the repository, not legal advice.

The documentation and translations are under Creative Commons Attribution 4.0, which is worth knowing if you want to reuse the docs in another project.

Editorial conclusion

Adopt GitJournal if you already keep notes in Markdown and want the repository itself to be the database, with GitHub, GitLab or a self-hosted Git host as the sync layer. Skip it if you need real-time collaborative editing, a conflict-free merge model, or an editor whose feature set is documented as thoroughly as its storage format. Before committing your archive, verify three things on your own repository: that the app can clone it, that a note written on the phone appears as a Markdown file with the YAML header you expect, and that a conflicting edit produces a result you can live with. The AGPL-3.0 licence on the author's code is the other thing to check before you build a modified version into a product.

Frequently asked questions

Official sources

1. GitJournal/GitJournal on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases