Are Git commits enough to document when software was developed?

Git records the development, but its dates are supplied by users

A Git repository can show successive versions of code, the changes between them and the explanations recorded in commit messages. A commit’s identifier links to a particular project tree, its parent commits and its metadata, as described in Git’s object model. This makes Git valuable for tracing development.

However, author and committer names and dates can be supplied by the person creating the commit. Git also supports replacing commits through operations such as amend and rebase. Rewriting a commit produces a different identifier; it does not silently alter the original commit under the same identifier. The Git documentation explains these controls.

A signed commit can help connect a commit to a signing key, but the signature alone does not independently establish when the work existed or who wrote every line. Preserve review discussions, task records and release correspondence when they help explain the code’s history.

Does hosting the repository on GitHub make a difference?

The same Git commit has the same identifier and embedded dates in a local repository and in a copy hosted on GitHub. Uploading it does not turn those dates into independently verified creation dates.

What a hosting service can add is a separate record of activity. GitHub’s activity view associates pushes, merges and branch changes with commits and authenticated users. Preserved service records can therefore help corroborate that particular code was present on the service at a particular time. Pull-request discussions and reviews can also help explain contributions and decisions.

For example, a commit may carry a January date but first be pushed to GitHub in March. A record of that March push can support its existence then; it does not independently verify the January date. Nor does the account that pushed the code necessarily identify its author or owner.

Keep useful service records separately from your repository backup. A Git clone does not include the host’s activity logs or review discussions. Retention also varies: GitHub’s Events API returns a limited recent timeline, not a permanent archive of every event.

Public or private matters separately

A hosted repository can be private. Keeping code on GitHub is not automatically the same as publishing it, just as keeping it locally is not by itself a confidentiality policy. Consider who has access, what they may do with the code and the agreements governing their involvement.

Making a repository public lets others access and copy the disclosed code. Changing it back to private does not undo that disclosure: GitHub confirms that existing public forks remain public. If the code contains confidential know-how or a potentially patentable invention, assess disclosure before publishing. WIPO explains that disclosure before filing can destroy patent novelty, subject to the applicable law and any grace period.

You do not need to make a repository public to create a dated record of it. Keep the decision about disclosure separate from the decision about preserving evidence.

Add a dated reference at meaningful milestones

If you need to support that a particular version existed by a particular date, an independent timestamp adds evidence beyond the dates supplied within your working tools. RFC 3161 describes this evidence-of-existence function. It does not establish the date the work first began or validate the authorship claims in the files.

At a release, delivery or important development milestone:

• Preserve the source snapshot and record its full commit identifier.
• Retain the repository history needed to examine that version, along with relevant reviews, tests and release notes.
• Check that the package includes any separately stored material needed to understand the work; a commit identifier alone is not a backup of the code.
• Timestamp the package and retain the exact certified bytes, certificate and verification information.

For example, certifying a release archive today can support that the archived code existed by today. It does not independently verify a commit date from six months earlier. The earlier chronology still needs its own supporting records.