Version history can help show how source code developed and who made particular recorded changes, but it rarely proves authorship by itself.
Understanding what Git commits and other records establish—and what they leave uncertain—can help you evaluate an authorship claim fairly.
What version history can show
Version history is a record of changes to files over time.
In Git, a repository stores commits: snapshots of tracked files accompanied by metadata such as an author name, email address, timestamp, and commit message.
Platforms such as GitHub and GitLab display these records and may add related information, including pull requests, reviews, and account activity.
These records can provide useful evidence about a project’s development.
They may show that code appeared in stages, that someone revised a function after feedback, or that a particular account submitted a change to a shared repository.
A sequence of coherent edits can help explain how a solution took shape.
However, commit metadata is not the same as independently verified identity.
A person can configure Git with another name or email address, and credentials or accounts can be shared or compromised.
Commits can also be amended, rebased, copied, or imported from elsewhere.
The record describes what the repository contains and the identities recorded in it; it does not automatically establish who physically typed the code.
Why a commit record is not proof on its own
Version-control history has limits as evidence.
A developer may write code locally for hours and commit it all at once.
Another may work in small increments, squash several commits into one, or contribute through a patch that someone else merges.
Different workflows produce different-looking histories, so the absence of gradual commits does not establish that code was copied or generated by AI.
Nor does a detailed history guarantee that every recorded change reflects original work.
Code can be pasted into a file and committed in several pieces.
A commit can include a substantial block borrowed from a library, tutorial, colleague, or earlier project.
The chronology can be genuine while the origin of some code remains uncertain.
For stronger context, reviewers can consider repository history alongside other evidence: issue discussions, design notes, code review, test results, development logs, and the contributor’s ability to explain the implementation.
Each source has its own limitations, but multiple consistent records can provide a more useful account than commit history alone.
Authorship, similarity, and AI detection are different questions
Code authorship asks who created or contributed to a particular piece of software.
Code similarity or plagiarism analysis asks whether code resembles another source, potentially including copied or improperly attributed material.
AI authorship classification attempts to estimate whether code may have been generated by an AI system.
These questions overlap in some investigations, but their answers are not interchangeable.
A similarity match may identify shared code without explaining why it is shared.
The code could come from an allowed dependency, a standard implementation, a common programming pattern, or copied work.
Reviewers need to examine the matched material, its context, and applicable rules before drawing a conclusion.
Likewise, a detector score is not proof that a person used AI, wrote the code, or violated a policy.
Automated classification can produce uncertain results, and source code often contains short, repetitive, or conventional patterns that make authorship difficult to infer from the text alone.
A score should be treated as a prompt for further review, not a verdict.
Turnitin has stated that its AI writing model does not reliably detect code.
Its AI writing report should not be confused with source-code similarity tools, which compare code against other code and address a different question.
The capabilities and intended use of any tool should be checked directly before relying on it.
How to assess a code authorship claim fairly
A sound review starts by defining the claim.
Is the question who made a commit, who wrote a specific function, whether code came from an external source, or whether a project used AI assistance?
Those are distinct inquiries and may require different evidence.
- Inspect the history in context. Review commits, branches, pull requests, and surrounding discussion.
Look for a coherent development narrative, while remembering that coding styles and workflows vary. - Check identity and repository controls. Consider how contributor identities were verified, who had access, whether commits were signed, and whether the repository’s history was rewritten or imported.
These checks strengthen context but may not prove who authored every line. - Review provenance and dependencies. Compare relevant code with documented dependencies, licenses, prior project versions, and potential source material.
A match alone does not establish misconduct. - Ask for an explanation or demonstration. A contributor’s ability to explain design choices, tradeoffs, and changes can add context.
It is not conclusive by itself, since people may forget details or work collaboratively. - Apply the relevant policy carefully. Institutional, workplace, and project rules vary.
Check what forms of collaboration or AI assistance are allowed and what evidence the applicable process requires.
If a source-code detector is used, its output should be described narrowly and transparently.
For example, a tool may flag a possible similarity or provide an authorship classification; that result does not independently verify identity or establish misconduct.
Codespy is an external source-code detector, but its mention is not an endorsement, and its results should be evaluated against the specific question and supporting evidence.
What version history can establish in practice
Version history is most useful as part of a broader evidence record.
It can document that a repository associated with an account changed in particular ways at particular recorded times.
When combined with verified contributor identity, review records, project communications, and a clear chain of custody, it may strengthen an account of who participated and how the code evolved.
Its limits matter just as much: commit metadata can be configured, shared, or altered; workflows can hide intermediate work; and a credible timeline does not identify the source of every line.
Treat history as evidence about recorded changes, then assess authorship, similarity, and AI use separately using the evidence and policies relevant to each claim.