Skip to content

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.


Now that you know what to avoid, continue with: