Git history and technical assessment
Git as a crime scene: what repository histories reveal
The presentation shows which technical and organizational questions a Git history can prompt. Repository data offers clues for an assessment, but it does not provide ready-made judgments about people or causes.
What it covers
Commit times, author shares, tags, merge histories, and frequently changed files can direct an assessment toward unusual parts of a system.
The evidence becomes useful when combined with build data, release processes, architecture knowledge, and conversations with the team. This context is needed to turn a pattern into a supported technical finding.
Main ideas
- Commit times and activity peaks identify periods whose working context may warrant review.
- A strong concentration among a few authors may indicate knowledge islands and provide a starting point for backup coverage and documentation.
- Tags and version patterns make parts of the release process visible. An assessment also needs CI, approvals, and deployment information.
- High change density and recurring conflicts direct attention to files that may concentrate architecture or testing problems.
- Credentials committed by mistake constitute a security incident. Affected secrets need to be revoked or rotated, and their use must be reviewed.
Limits and current status
- Repository data proves neither stress nor motivation, communication quality, or individual performance. It provides hypotheses for further review.
- "git blame" shows the most recent change to a line. It does not establish professional responsibility or fault.
- Cleaning the history does not make an exposed secret safe again. Rotation, revocation, and a review of possible access remain necessary.
- The slides reflect the talk given on April 1, 2026. A system assessment requires current repository and process data from the specific project.
Original presentation
Presentation - Tatort.pdf
22 pages • 8.5 MB