Git Logs API.
Trace source changes without confusing them with release outcomes.

Git logs explain repository history, while hosting activity explains actions around that history. A useful design keeps those sources connected without treating them as identical. Start with exact revision identifiers, then add push, review, automation, and permission events from the systems where those actions occur. Preserve enough provenance to tell which system made each assertion.

Keep exact revisions alongside useful labels

A branch or release label makes navigation easier, but it can point somewhere different later. Record the full resolved commit identifier for a build or deployment decision. Keep the repository identity with it so the reference remains meaningful across a fleet of projects. If a workflow tests a generated merge revision, record that tested revision rather than assuming it is the contribution's head commit.

Use human-readable subjects as supplementary context. They are user-controlled text and should be safely encoded when displayed or exported. Avoid copying complete patches into general-purpose diagnostic storage when a source reference answers the question.

Record actions where they are observed

Capture the event type, authenticated actor, source event identifier, and outcome for important repository activities. Distinguish the author recorded in a commit from the account that pushed, reviewed, or approved a change. Explain service identities clearly so automated actions do not appear to be unexplained human activity.

Keep permission and branch-policy changes available to the people investigating release decisions. Document collection gaps and retention boundaries. A missing repository event should remain missing evidence, not become a claim that no action occurred.

Carry revision identity into delivery

Join the source revision to a build attempt, then connect that attempt to its artifact and deployment. A successful commit push is not evidence of a successful release. The Git and code audit trail guide walks through this complete chain, including reruns and rollbacks.

Continue with code and build logging to define the next set of events. The suggested fields below describe a starting point; choose names and scopes that fit your repository hosting and audit requirements.