A project folder can contain files that look equally important but have very different roles. The Markdown document you edit is not the same kind of artifact as the PDF exported from it. Raw measurements are not the same as a chart generated from those measurements.
The practical rule is simple: protect what you cannot reliably recreate, and document how to recreate everything else. This requires more judgment than sorting files by extension.
Source and generated describe roles
A source file is an input that a person creates, edits, records, or collects. A generated file is an output produced from other files by a defined process.
Consider a class report:
report-project/
├── README.md
├── data/
│ └── observations.csv
├── src/
│ └── make_chart.py
├── report.md
└── build/
├── chart.png
└── report.pdf
The observations, program, report source, and reproduction instructions are sources. The chart and PDF are generated outputs if the documented process can recreate them.
The same format can play either role. A photograph collected during fieldwork is a source even though it is not plain text. A CSV exported from a program is generated if the program and original data can reproduce it. A PDF is usually an output, but a PDF supplied by an instructor may be an irreplaceable input.
Ask about the file’s role in this project, not merely its extension.
Use three questions to classify a file
1. Must a person edit or collect it?
If a person wrote, measured, designed, photographed, or deliberately configured the content, treat it as source unless another authoritative copy exists.
Examples include:
- source code;
- Markdown or Word drafts;
- raw laboratory or survey data;
- original photographs and drawings;
- configuration written for the project; and
- instructions that explain the build.
2. Can a documented process recreate it?
An output is only reproducible when you have all required inputs, instructions, software, and dependencies. “The program made it” is not enough.
Test the claim. Move a copy of the output outside the project, remove the working copy only when safe, run the documented process, and compare the new result with what you expected. Do this on a practice project before relying on the method.
3. Is recreation practical?
Generated does not mean worthless. Preserve an output when:
- a course requires that exact deliverable;
- regeneration needs unavailable software or services;
- the computation is expensive;
- an external data source may change;
- the output records a signed, reviewed, or submitted state; or
- another person needs the result without the build environment.
Keep the editable source as well. A submitted PDF records what you delivered, while its source lets you make a later revision.
Source, output, cache, and temporary files differ
Two additional categories help:
- A cache stores data that speeds later work but can normally be recreated.
- A temporary file supports an operation and has no intended long-term role.
Compiler objects, downloaded package caches, thumbnail databases, and editor scratch files often fit these categories. They can consume space and create noise without preserving project knowledge.
Do not delete unfamiliar files merely because they look temporary. First identify which tool created them, close the tool, check its documentation, and test cleanup on a safe copy.
Git and backup answer different questions
Git is useful for source files whose changes you want to inspect and explain. Generated build directories often do not belong in version history because they can obscure the changes that matter.
A project .gitignore can name intentionally untracked files. The official
Git documentation for gitignore notes
that projects commonly use these rules for generated build files. It also
explains an important limit: ignore rules do not affect files Git already
tracks.
Do not turn that convention into a rigid rule. A small generated reference file may need to be reviewed with the source. A required deliverable may belong in a release or submission archive. Large binary source files may need storage outside ordinary Git.
Backup has a broader job. It should protect irreplaceable source material
whether or not Git tracks it. It may also preserve selected outputs that are
costly or necessary to keep. A .gitignore file does not create a backup, and a
Git repository does not automatically protect data stored only on one device.
Write a source-versus-output record
Choose one project and write a short record titled Source and output inventory — [project]. Give each important file or folder its own paragraph answering:
- Is it
source,generated,cache, or a submitted record? - How is it created or regenerated, and what exact command or application performs that step?
- Should it remain in Git, in backup, in both, or in neither?
- Why is that choice appropriate given privacy, size, collaboration, rebuild cost, or submission requirements?
For example, explain in one paragraph that build/chart.png is generated by
the chart script and is usually cheap to recreate, while data/observations.csv
may need protection as source material. Use unknown when classification or
regeneration is unresolved. Do not fill in a Markdown inventory table.
The distinction between “usually” and “maybe” is deliberate. Course rules, privacy, file size, collaboration, and rebuild cost change the answer.
For each generated item, write the exact regeneration step in README.md or
another project document. Then test one step. If the rebuild fails, the output
is not yet safely disposable.
Common mistakes
- Calling every plain-text file source. A generated CSV or HTML file is still generated.
- Calling every binary file disposable. Original media and supplied documents may be source material.
- Ignoring the build instructions. Code without dependencies, commands, and inputs may not reproduce anything.
- Deleting before testing. Demonstrate regeneration on a safe copy first.
- Committing every output. Extra files can make meaningful changes harder to review.
- Backing up only the final PDF. The deliverable may survive while the editable work is lost.
Do this now
Start with one generated file and trace it to its source, generation step, and verification check. Expand the inventory only when the first boundary is clear.
Inventory one small project. Label each item source, generated, cache, or
temporary. For every generated item, identify the inputs and command or
application needed to reproduce it. Mark what belongs in Git, backup, both, or
neither.
If the inventory has many items or unresolved classifications, use the guided chatbot workflow to collect the record one question at a time. Verify classifications against the project rather than accepting plausible labels.
Do not delete anything during the first inventory. Classification comes before cleanup.
Log what you learned
Record only:
- Result: What did the action produce?
- Evidence: What observation, test, or source supports that result?
- Next action or unresolved question: What should happen next?
Next, examine why plain text makes sources especially easy to compare, search, transform, and review across Git, command-line tools, and AI.