A Commit History for the Bench: Twelve Months of Public Protocol Version Control

Twelve months ago, the McKnight Lab made a decision that sounded simpler than it was: every core molecular biology protocol we rely on would live in a public repository, under version control, with its full edit history visible to anyone. Not a PDF pinned to a shared drive. Not a binder on the shelf with handwritten marginalia. A living document with commits, branches, and an issue tracker.

We expected tidiness. What we got was a year-long lesson in what protocols actually are, how they drift, and where open tooling helps a bench scientist and where it quietly gets in the way.

The Drift We Could Not See

The most immediate change was not collaborative. It was forensic.

Before the move, our protocols were stable in the way that a river is stable: the name stayed the same while the contents shifted. A buffer concentration nudged by one postdoc and never reverted. A centrifugation step quietly extended because a rotor was swapped. A note about a kit lot that stopped being manufactured in 2022 but which everyone still read past.

Version control made those changes legible. Within the first month we found eleven undocumented divergences between what the repository said and what people were actually doing at the bench. None of them were catastrophic. All of them mattered, because a protocol that no longer matches practice is not a protocol; it is a rumor with formatting.

The fix was not technical. We introduced a rule that any change made at the bench must be committed within the same week, with a one-line reason. The rule is boring. It has also been the single most effective quality-control measure we adopted this year.

An Outside Issue That Improved Our PCR Cleanup

The part of the year we did not anticipate was the value of strangers.

Roughly four months in, an issue appeared on our PCR cleanup protocol from a research technician at a mid-sized university we had never worked with. They had tried our silica-column alternative and found that our elution volume, combined with our specified incubation time, was leaving measurable carryover on low-input templates. They included their own data, a suggested two-step elution, and a note that they had only tested it on bacterial gDNA.

We reproduced their result in-house within two weeks. The two-step elution is now the default in the repository, credited in the changelog to a contributor outside the lab.

This is the case for open protocols in miniature. Our internal review had missed the problem not because we were careless but because we had standardized on a template input range that never stressed the step. Someone with different samples saw what we could not.

We have since added a short "known limitations" section to every protocol, listing the input types and conditions we have actually validated. It is uncomfortable to publish the edges of your own competence. It has also generated more useful issues than any appeal for feedback we could have written.

Where the Model Broke Down

A candid accounting has to include the friction, and there was plenty.

For lab members who do not live in a terminal, the repository was a foreign country. Cloning, branching, and pull requests are learnable, but they are not free, and asking a first-year student to learn Git in the same month they learn sterile technique is a real cost. We underestimated it.

Our response was to stop pretending the tool was neutral. We designated one member as the protocol steward, whose job includes committing changes on behalf of anyone who would rather write them on a sticky note. We also maintain a rendered, human-readable version of every protocol that updates automatically from the repository, so the bench-facing document is never a Git command away.

The deeper friction was conceptual. A repository invites the assumption that a protocol is a document to be edited, when in practice it is a claim about how a physical procedure behaves. Git tracks text. It does not track the lot number of an enzyme, the humidity in the cold room, or the fact that a step only works when a particular person does it. We learned to keep a separate, private record for those variables and to treat the public repository as the distilled, reproducible core.

What GitHub Is Not

We want to be explicit about a boundary that took us a few months to articulate: a public protocol repository is not a lab notebook, and treating it as one is a mistake with real consequences.

A notebook records what happened, including the failed attempts, the deviations, and the reasoning that did not pan out. A protocol repository records what should happen, in a form another lab can follow. Conflating them produces protocols cluttered with anecdote and notebooks scrubbed of the honesty that makes them useful. We keep them separate, and we say so in the repository's README.

A Playbook for Labs Considering the Same Move

If your lab is weighing public version control for protocols, four things we would do again:

Start with the procedures you actually repeat, not the ones that look impressive. Our first commits were for transformations and minipreps, not for the assays we run twice a year.

Assign a steward before you assign a repository. The tool will not maintain itself, and a neglected repository is worse than a static PDF because it implies currency it does not have.

Publish your validation range alongside your protocol. The issues you receive will be more useful, and the ones you cannot address will be honest.

Render for the bench. The people running the protocol should never need to know what a merge conflict is.

A year in, the repository has forty-one protocols, a changelog with contributions from six institutions, and a small but real record of corrections we would not otherwise have made. It has not replaced our notebooks, our training, or our judgment. It has made the parts of our practice we can share genuinely shareable, which is, we think, the point.