Preserve the repository before trying to make it persuasive
Do not start with an interactive rebase, squash or new explanatory commits. Those operations can replace the original sequence. Capture the working tree, relevant branches, tags, commit identifiers and configured remotes. Record the preservation time and whether uncommitted files existed. Keep a bundle or copy separate from the repository used for continued work.
Identify whether development occurred locally, on a hosting platform or across several repositories. A hosted remote may retain pull requests and review events; a local commit may never have been pushed. Describe that distinction rather than treating one location as automatically complete. Never disclose a private repository publicly or use another person’s credentials simply to strengthen an evidential account.
Read the intellectual change, not merely the chronology
A long history is not automatically informative. Choose milestones such as the first workable structure, import of a data source, implementation of a method, correction after feedback, addition of tests and the submitted state. Explain from the diff which decision becomes visible. A commit containing thousands of generated files may say less about independent work than a small reasoned change with a relevant test.
Inspect parents and branches. A merge can combine other contributors’ commits; a cherry-pick may repeat a change under a new identifier. A submodule points to another repository. Binary files often reveal only that bytes changed. Do not claim substantive development where no readable source or companion record supports it.
Commit messages may preserve the stated purpose at the time, yet remain author-supplied metadata. Connect them to code, tests, issues or review comments. For prose, a diff reveals insertions and deletions without establishing where inserted wording came from. Research notes, citations and earlier files can address that separate provenance question.
Distinguish stored identity fields from personal authorship
A commit name and email are configured locally. They associate an object with a stated identity but do not verify the individual operating the device. Author date and committer date may differ and can also be set locally. Hosting events or external reviews can supply further context without removing the need to examine content.
With sound key management, a cryptographic signature shows that a particular key signed a commit. It does not prove who controlled that key at the moment or whether the work was independently conceived. Prefer “the platform marks this commit as verified with key X” to “the signature proves that I wrote it”.
Git records committed states only. Reading, sketches, conversations, local experiments and discarded files may be absent. A history imported after the event remains a reconstruction. The broader guide to using version history as evidence connects Git with other records.
Build a Git evidence bundle that can be checked
Start with repository identity, preservation date, relevant branch and submission commit. Follow with the timeline, a small number of annotated diffs and an appendix register. Supply commands or platform views that allow a technically competent reader to reproduce your selection. If the project contains secrets, personal information or third-party code, arrange a protected inspection route rather than disclosing everything.
- Preserve the original state and uncommitted work separately.
- Retain complete commit hashes in the appendix.
- State time zones and both author and committer dates.
- Connect each milestone to an intellectual decision.
- Cite tests and external records only where they exist.
- Identify merges, imports and generated content.
- State limits concerning identity, completeness and time.
The examination procedures hub places the bundle in context. For non-technical corroboration, see supervisor feedback as context. The one foundation link is academic writing and evidence.
Run a final reader check: can another person locate every cited commit, reproduce the selected comparison and distinguish stored metadata from your interpretation? If not, improve the index rather than adding a stronger conclusion. Preserve the exact bundle reviewed so later repository changes cannot silently alter the evidence set.