Version control
Version control for lab protocols.
The idea behind Git — version, diff, attributed history — adapted for wet-lab methods. Not a command line and not a folder of protocol_final_v3_FINAL.docx: one canonical protocol with a living fix history that everyone can see.
The problem
Most labs don't version protocols. They copy them.
The working copy of a method usually lives in a Word file, a shared drive, or a Google Doc — and it gets duplicated every time someone tweaks it. A bench scientist saves v3_FINAL, emails it on, and the next person renames it again. Within a year the lab has six divergent versions and no one is sure which one actually works.
None of those copies record why a step changed. The reason a block was switched from milk to BSA, the buffer that fixed a transfer, the antibody lot that ruined a week — that knowledge lives in someone's head or notebook, not in the protocol. When they leave, it leaves with them. That's the reproducibility leak version control is meant to close.
How jnar does it
Version control built for methods, not source code.
Four things make a protocol genuinely version-controlled on jnar. All four are live today.
Living fix history
Every protocol carries a visible record of what broke, who fixed it, and why — version by version. The change and its reason live together, not in someone's lab notebook.
Precise, file-hash-aware diffs
Step edits, reorders, and attachment swaps are tracked exactly. You see what changed between any two versions — not a fuzzy “last edited” timestamp.
Contributions converge, not fork
Replications and improvements land as structured contributions against the original. One canonical protocol gets more reproducible over time, instead of scattering into copies.
ORCID credit per version
When an author integrates an accepted change, the contributor is named in the fix history and the version diff. Credit compounds across versions instead of disappearing.
Git for lab protocols
If you know Git, you already get it.
jnar borrows the mental model developers use to keep code sane, and maps it onto protocols. The vocabulary translates cleanly:
| In Git | On jnar | What it means |
|---|---|---|
| commit | A new protocol version | Snapshots the method at a point in time. |
| pull request | A contribution | A replication, fix, or improvement proposed against the original. |
| merge | The author integrates | Accepted changes roll into a new canonical version. |
| blame | Fix history + ORCID | Who changed what, when, and why — attributed. |
| fork | ✗ — it converges | No scattering into copies; contributions land on one canonical protocol. |
To be clear: jnar is not literally Git. There's no command line, no repositories to clone, and no merge conflicts to resolve by hand. It takes the ideas that make version control work and builds them into a tool a wet lab can actually use.
For the whole lab
Version control across your whole group.
On a team workspace, version control stops being one person's habit and becomes the lab's. Methods, replications, and fixes stay private to your group, versioned and attributed, with an internal review queue before anything is integrated.
- ✓Private, versioned protocols for your group
- ✓Internal review & moderation before a version lands
- ✓New members inherit the lab's living methods on day one
Versioning, the fix history, precise diffs, convergent contributions, and ORCID attribution are live today. DOI minting for published versions is on the roadmap, not shipped — we mark roadmap items as roadmap, and we don't borrow the word “Git” to imply tooling jnar doesn't have.
FAQ
Version control for protocols, answered.
Is there version control for lab protocols?
Yes. On jnar, every protocol is a versioned object: each published change creates a new version with a precise diff, and the full history — including what failed and how it was fixed — stays visible. It's the version-control idea applied to wet-lab methods rather than source code.
Can you use Git for lab protocols?
Not directly, and you usually don't want to. Git is built for plain-text source code and a command line — it doesn't understand protocol steps, materials, attachments, or who deserves scientific credit. jnar brings the useful ideas behind Git — versioning, diffs, attributed history, proposed changes — to protocols, without a CLI or repositories to manage.
How is this different from versioning a Google Doc or a Word file?
A Google Doc tracks edits to prose; it doesn't model a protocol. jnar diffs the actual structure — step reorders and attachment swaps included, file-hash aware — records why a step changed (not just that it did), keeps negative results as first-class data, and attributes every change via ORCID. And it's one canonical method, not a folder of protocol_final_v3_FINAL files.
Does jnar fork protocols like GitHub?
No — and that's deliberate. Forks scatter a method into divergent copies that nobody reconciles. On jnar, replications and improvements land as contributions that converge on a single canonical protocol, so the method gets more reproducible over time instead of fragmenting.
Does my whole lab get version control?
Yes, on the team tier. A team workspace gives your group private, versioned protocols with an internal review queue, roles, and ORCID team credit — so a new member inherits the lab's living methods on day one. See /for-labs.
What's shipped versus on the roadmap?
Versioning, the fix history, precise diffs, convergent contributions, and ORCID attribution are live today. DOI minting for published versions is on the roadmap, not shipped — we mark roadmap items as roadmap, never as features we already have.
Put a protocol under version control.
Bring an existing method in and start recording its versions and fixes. Your first AI conversion is free.