GitHub Sync
Connect a Meldoc project to a GitHub repository and the two stay in step, without you running anything in CI. Documentation moves both ways.
From the repository into Meldoc. What lands on the default branch arrives in the project — new documents, edits, deletions.
From Meldoc into the repository, as a pull request. What people write in the web leaves as a branch and a pull request, never as a direct commit to the default branch. That is deliberate: protected branches are the normal case, and a sync that only worked on unprotected repositories would work on the careless ones and fail on the careful ones.
This is the same machinery as the Meldoc CLI, running on the server. The rules about what a document is, what its alias is and how two edits merge are shared between them, so a file pushed by meldoc push and the same file picked up by the sync produce the same document.
What you need
- A GitHub repository you can install an app on.
- Project administrator rights in Meldoc for anything that changes the connection; anyone who can read the project can see what the sync is doing.
Repository sync is available on every plan, though a workspace can have it switched off — the panel says so plainly rather than hiding itself, so you can see why nothing is happening.
Where to start
- Connect GitHub — install the app, choose which repositories Meldoc can see, and pair one with a project.
- How a Sync Runs — what starts a sync, what it does, and how to read a run.
- Resolve a Conflict — when both sides changed the same file.
- Pre-Merge Check — tell a pull request what the sync will do with it, before it merges.
- Documentation Review — the second check: what this pull request makes untrue in the documentation.
- Disconnect — unpairing a project, and disconnecting GitHub altogether.
What’s next?
Connect GitHub — Set the connection up.
Meldoc CLI — The same synchronisation from your own machine.