Common first mistakes
Summary — The Five Principles
Most early mistakes come from applying shared‑drive or notebook habits to a system built for traceability.
Keep these core principles in mind:
- One asset = one repository
- Design commit templates with forethought (ideally before starting work)
- Commit early and at meaningful checkpoints
- Keep repositories clean and structured—CellRepo is not cloud storage
- Write clear, informative commit messages
If you follow these, you will avoid 90% of common pitfalls.
Mistake 1 — Not designing commit templates ahead of time
❌ Starting work without any template planning, or building templates on the fly without thinking about what needs to be recorded.
Why it’s a problem:
You risk inconsistent fields, missing metadata, and confusion later— especially when collaborating.
Do this instead:
- Spend a few minutes upfront deciding what’s important to track.
- Sketch it in your notebook.
- Start from a public template, fork it, and edit it for your workflow.
- Remember templates can evolve—but a thoughtful starting point makes everything cleaner.
Mistake 2 — Putting multiple strains in one repository
❌ Storing multiple strains/constructs in a single repository.
Why it’s a problem:
Histories become ambiguous and cannot be interpreted clearly.
Do this instead:
- One repository per biological asset.
Projects group work; repositories track individual entities.
Mistake 3 — Waiting until everything is “final” before committing
❌ Only committing once the entire experiment is complete.
Why it’s a problem:
You lose decisions, context, failed attempts, and evolution of thought.
Do this instead:
- Commit at meaningful milestones—the moments you would normally document in a notebook.
Commits = checkpoints, not polished summaries.
Mistake 4 — Treating CellRepo like cloud storage
❌ Uploading every file “just to have it somewhere.”
*Why it’s a problem:
Unstructured dumps bury the meaningful information.
Do this instead:
- Add data that’s relevant to the update.
- Use clear descriptions and structured fields.
CellRepo is for history, not file dumping.
Mistake 5 — Skipping the first (baseline) commit
❌ Creating a repository but never making the first real commit.
Why it’s a problem:
There’s no reference point—future commits lack context.
Do this instead:
- Create a first commit describing the origin, genotype, or starting state.
This becomes “time zero.”
Mistake 6— Overthinking structure at the beginning
❌ Trying to design the perfect hierarchy before doing any real work.
Why it’s a problem:
CellRepo is meant to evolve with your project.
Do this instead:
- Start simple (one project, one repository, basic templates).
- Adjust structure as your needs grow.
Mistake 7 — Ignoring commit templates
❌ Writing only free‑text commit messages.
Why it’s a problem:
Inconsistent information, missing metadata, hard‑to‑compare history.
Do this instead:
- Use commit templates for clarity and consistency.
- Templates protect future‑you from digging through messy notes.
Mistake 8 — Using labs to control permissions
❌ Expecting labs to control repository visibility.
Why it’s a problem:
Labs are organisational. They do not control access.
Do this instead:
- Set access and permissions at the project or repository level.
Treat labs like folders, not security.
Mistake 9 — Writing unclear commit messages
❌ Messages like “update,” “final,” or “fix.”
Why it’s a problem:
They are meaningless later.
Do this instead:
- Answer: What changed, and why does it matter?
Clarity saves time later.
Mistake 10 — Being afraid of making mistakes
❌ Avoiding commits out of fear of “messing up the history.”
Why it’s a problem:
You lose traceability.
Do this instead:
- If something is wrong, make another commit explaining the correction.
CellRepo preserves history by design.
Quick checklist
Before continuing:
- Does each strain/construct have its own repository?
- Did I make a baseline commit?
- Am I committing at meaningful checkpoints?
- Are my commit messages clear?
- Did I design commit templates thoughtfully?
- Is my workflow simple and evolving, not rigid?
If yes—you’re using CellRepo correctly.