Common first mistakes
When starting with CellRepo, most problems don’t come from the software.
They come from carrying over habits from: - lab notebooks - shared drives - ad-hoc folders - “final_v3_really_final” files
CellRepo works differently because it is built around history and traceability, not file storage.
This page highlights the most common mistakes new users make, and how to avoid them.
Mistake 1 — Putting multiple strains in one repository
❌ “This project has 5 strains, so I’ll keep them all in one repository.”
This is the most common structural mistake.
A repository should track one biological asset only.
If you mix: - multiple strains - multiple constructs - multiple unrelated entities
then: - commit history becomes ambiguous - you cannot tell which change affected which strain - reproducibility suffers
Do this instead
Create: - one repository per strain or construct
Projects group work.
Repositories track one thing.
Mistake 2 — Waiting until everything is “final” before committing
❌ “I’ll commit once the experiment is complete.”
This defeats the purpose of version control.
Commits are not “final versions”.
They are checkpoints.
If you only commit at the end: - early decisions are lost - failed attempts disappear - reasoning becomes unclear - you can’t trace how you got there
Do this instead
Commit when: - something meaningful changes - you reach an experimental milestone - you would normally write something in your lab notebook
Think: milestones, not perfection
Mistake 3 — Treating CellRepo like cloud storage
❌ “I’ll just upload all files here as a backup.”
CellRepo is not Dropbox or Google Drive.
It is designed for: - structured recording - traceability - scientific history
If you dump random files: - repositories become noisy - important information gets buried - history becomes harder to understand
Do this instead
Add: - meaningful data - structured updates - clear descriptions
Keep commits intentional.
Mistake 4 — Skipping the first (baseline) commit
❌ Creating a repository but never making the first commit.
An empty repository has: - no history - no reference point - nothing to compare against
Without a baseline: future changes have no context.
Do this instead
Create a first commit immediately that records: - origin of the strain - initial design or genotype - how it was created
This becomes “time zero”.
Everything else builds on it.
Mistake 5 — Overthinking structure at the beginning
❌ “I need to design everything perfectly before I start.”
New users often spend too much time trying to: - design the perfect hierarchy - create all templates in advance - define every rule
CellRepo is designed to evolve with your work.
You can always: - add repositories later - split things - create new templates - reorganise projects
Do this instead
Start simple: - one project - one repository - basic commits
Refine later.
Mistake 6 — Ignoring commit templates
❌ Writing free-form commit messages only.
Free text works short-term.
But over months or years: - information becomes inconsistent - fields get forgotten - comparisons become harder
Commit templates exist to: - standardise records - reduce missing metadata - make collaboration easier
Do this instead
Use templates when: - multiple people contribute - you want consistent fields - experiments follow similar structure
Templates help future you just as much as your team.
Mistake 7 — Using labs to control permissions
❌ “If I put this repository in a lab, only that lab can see it.”
Labs do not control access.
Labs are only for: - grouping - organisation - structure
Access is controlled at: - project level - repository level
Do this instead
Use: - visibility settings - read/write/admin roles
Treat labs like folders, not security.
Mistake 8 — Writing unclear commit messages
❌ Messages like: - “update” - “fix” - “final” - “test”
These become meaningless very quickly.
Months later, you won’t remember what changed.
Do this instead
Answer one question:
What changed, and why does it matter?
Good examples: - “Initial construction of knockout strain” - “Confirmed genotype by sequencing” - “Updated plasmid design after optimisation”
Clarity saves time later.
Mistake 9 — Fear of making mistakes
❌ “If I commit something wrong, it will ruin the history.”
CellRepo is intentionally designed so that: - commits are immutable - corrections are new commits - history stays transparent
This is a feature, not a problem.
Science is iterative.
Do this instead
If something is wrong: - make another commit explaining the correction
Traceability is more valuable than hiding errors.
A simple mental checklist
Before starting new work, ask:
- Does each strain have its own repository?
- Did I create a baseline commit?
- Am I committing at meaningful checkpoints?
- Are my messages clear?
- Am I keeping things simple?
If yes, you’re using CellRepo correctly.
What to read next
Now that you know what to avoid, continue with:
- CellRepo vocabulary
- or follow a practical example in
Workflows