Commit templates
A commit template defines the structure of information recorded in every commit.
If repositories track what asset you are working on,
commit templates define how changes to that asset are documented.
They are the foundation of consistent, traceable experimental history.
The mental model
Think of commit templates like:
- a lab notebook page layout
- a standard experimental form
- or a checklist you fill every time
Instead of everyone writing notes differently, everyone follows the same structure.
This makes records:
- comparable
- searchable
- easier to interpret months or years later
How templates relate to repositories
Each repository:
- represents one biological asset
- uses one template to structure its commits
The template determines:
- which fields appear when committing
- which information is required
- how history is organised
So:
Repository → what you track
Template → how you record it
What a template contains
Templates are made up of fields.
Each field captures one piece of experimental information.
Common examples:
- summary or title
- genotype
- protocol or method
- conditions or parameters
- observations or results
- attachments (files, images, data)
- notes
Fields can be:
- structured (fixed inputs)
- free text
- optional or required
You decide how detailed or flexible the template should be.
Template scope (who can use it)
Templates can exist at different levels:
- Private → only you can use it
- Organisation → shared with your team
- Public → available to everyone
If you work alone, you’ll typically use private or public templates.
If you work in a lab or team, organisation templates help standardise documentation.
Why templates are separate from repositories
Templates are intentionally not tied to one repository.
This allows you to:
- reuse the same structure across many assets
- update or improve templates over time
- keep commit history stable even if templates change
For example:
You might use one “Strain engineering” template for 20 different strains.
This keeps documentation consistent without duplicating setup work.
Example
Imagine your lab tracks bacterial strains.
Your template might include:
- strain name
- modification performed
- protocol reference
- growth conditions
- sequencing results
- notes
Every commit then follows the same structure.
Six months later, you can easily compare strains because every record contains the same fields.
Best practices
Start simple:
- include only essential fields
- avoid too many required inputs
Then refine:
- add fields once patterns emerge
- standardise across your team
Templates should help documentation, not slow it down.
Key idea
Templates guide how you record information.
They do not control permissions or access.
Access is managed separately through projects and repositories.