Versioning preserves meaning, not merely copies
A folder can contain dozens of files yet reveal almost nothing about its history. Labels such as final_new_really.xlsx do not identify the source or explain a change. A sound version system answers three questions: Which file was the untouched input? What changed, by whom and for what reason? Which exact state generated a value, chart or quotation in the dissertation? That requires a protected source, deliberately named milestones and a concise change record.
Not every save needs to become a formal release. Distinguish the application’s editing history, ordinary daily work and research milestones. A new milestone is justified when variables, exclusions, coding, analysis decisions or reported results change. Keep those states read-only or protect them with checksums. Backup and synchronisation support this arrangement, but neither provides a human explanation of what a version means.
Design a filename that works before the file is opened
Use a small set of elements in one stable order: project code, content, status, ISO-style date and a version number. Avoid spaces, obscure punctuation and personal information. For example, pathways_survey_clean_2026-08-22_v03.csv is sortable and reasonably descriptive. The word clean is meaningful only if a cleaning log defines the operations. Agree once what raw, interim, clean and release mean in this project.
A date and version number solve different problems. The date positions the file in time; the number shows a planned sequence. Do not restart the convention whenever a correction is made. In collaborative work, designate one location as authoritative and record the roles allowed to promote a file to release. Contributor initials can help during drafting but do not replace ownership, review and a central log.
Trace a claim backwards through the analysis
A defensible chain connects a sentence, table or figure to its output file, analysis step, software environment, prepared dataset and preserved source. Give generated outputs unique names and record the command and inputs that created them. In graphical software, capture consequential filters, worksheets, pivot states and export options. Screenshots can support the trail, but searchable text should carry the explanation.
Test the chain in both directions. Begin with a reported result and locate the output, procedure and input. Then start at the original data and follow every transformation forward, looking for unrecorded manual copies. If a past step cannot be reconstructed, state the gap and improve the next run. Inventing a plausible history after the event would turn a documentation weakness into a misleading record.
Use Git, spreadsheets and cloud history for what they do well
Git is effective for text-based scripts and documentation because it records line-level changes and supports named releases. Commits should represent coherent work and carry informative messages. Large binary files and sensitive research records should not be pushed to a public repository by default. Use suitable institutional data storage or specialist versioning and keep only safe identifiers and retrieval instructions in code.
Spreadsheets need a particularly explicit log because formula edits, filters and overwritten cells can coexist. Export significant states where appropriate and retain the source workbook as documentation of formula logic. Cloud history may provide convenient restoration, but retention periods and export options vary. Perform a real recovery test: a historical file is valuable only if it can be retrieved, opened and linked to a documented state.
Keep sensitive and subjective labels out of filenames
Terms such as “correct”, “nice” or “definitive” age badly and explain no research decision. Participant names, diagnoses, confidential group labels and direct identifiers can leak through synchronisation alerts, backup listings and shared links. Use pseudonymous project codes where authorised and hold sensitivity information in a controlled inventory.
Do not rename a release without updating scripts, manifests and documentation that refer to it. Where a name must change, log both old and new values. Automatically generated timestamps are helpful for uniqueness but cannot state the methodological reason for a revision. The explanation still belongs in the change record.
Audit the release before results are signed off
- Is the original data state unchanged and protected against accidental overwrite?
- Is exactly one working or release state designated as authoritative?
- Does the log explain every consequential transformation and link to evidence?
- Can every reported output be tied to the input and software version actually used?
- Can an earlier release be restored from the backup or archive and interpreted correctly?