There is a category of bug that never shows up in your test suite, never throws an exception, and can still get an entire project rejected: unclear ownership in your git history. I learned this the expensive way on a two-person Go web project where the application itself worked correctly and still failed its audit, purely because it was impossible to tell from the commit log who had actually written which parts of the code.
This is not a story about git commands. It is a story about what "collaboration" actually needs to look like in version control when someone else is going to evaluate your individual contribution, and what to do when you discover, partway through a project, that your history does not support that evaluation.
The setup
The project was a web application built with a partner, split roughly into a backend API and a frontend consisting of templates, display logic, and styling. We worked the way a lot of early collaborators work: sharing a single local checkout at points, committing under whichever git identity happened to be configured on the machine at the time, and occasionally pushing each other's uncommitted changes to save time. None of this was malicious. It was just imprecise, and imprecision in git history reads, from the outside, exactly like dishonesty.
What the audit actually checks
An audit of a collaborative project is not primarily checking whether the software works. It is checking whether the git history is a truthful record of who did what. That distinction matters enormously and most people do not internalize it until it costs them. A working application built by two people with a commit history that cannot distinguish their contributions is, from an evaluation standpoint, indistinguishable from a project where one person did all the work and the other person's name is attached for free.
The specific failure in my case was that a meaningful chunk of frontend commits were attributed to my partner's git identity, despite the actual authorship being mine, because we had been sharing a working directory without reconfiguring user.name and user.email between sessions. There was no way, looking at the log, to verify that I had done the frontend work at all. The audit did not accuse anyone of lying. It just correctly identified that the evidence needed to confirm individual contribution was not there, and treated that absence as a failure condition.
The fix: rebuild on a clean branch under your own identity
Once you are in this situation, trying to rewrite history on the shared branch is usually worse than starting fresh, especially if your partner has already pushed further work on top of the tangled commits. Rewriting shared history creates its own trust problems and can look like you are trying to obscure something rather than fix it.
What worked was creating a new branch specifically for my portion of the work, checking out the current state of the frontend files, and recommitting them incrementally under my own git identity, with commit messages that actually described the work in a way that a reader unfamiliar with the project could follow.
First, confirm which identity git will actually use for new commits, since this is the exact thing that went wrong the first time:
git config user.name
git config user.email
If either one is missing or wrong for the current session, set it explicitly, and for a shared machine, set it locally to the repository rather than globally so it cannot silently apply to someone else's work later:
git config user.name "Your Actual Name"
git config user.email "your-actual-email@example.com"
From there, I created a dedicated branch off the current shared state:
git checkout -b coley-frontend
Rather than trying to cherry-pick or rebase the tangled commits, which would have carried the wrong authorship metadata along with them, I treated the frontend directory as a fresh contribution. I removed the frontend files, then reintroduced them in a sequence of small, honestly-described commits:
git rm -r --cached templates/ static/
git commit -m "remove frontend files pending rebuild under correct authorship"
# then, restoring and recommitting incrementally:
git add templates/base.html templates/layout.html
git commit -m "add base and layout templates"
git add static/css/main.css
git commit -m "add primary stylesheet"
git add templates/thread.html templates/post.html
git commit -m "add thread and post display templates"
Each commit was small enough and specific enough that its content matched its message, which is a detail auditors specifically look for. A commit message that says "add thread and post display templates" attached to a diff that actually touches unrelated backend files is its own kind of red flag, arguably worse than vague messages, because it suggests the commits were constructed after the fact rather than reflecting the actual order of work.
Verifying authorship before you submit
Do not just trust that the rebuild worked. Check it the same way an auditor would:
git log --author="your-actual-email@example.com" --oneline
This should show a coherent, chronological set of commits that plausibly represents the frontend work you are claiming. If commits from your partner's identity are interleaved in a way that does not make sense, or if your commits are all clustered in a suspicious burst right before a deadline, that is worth noticing and addressing before someone else notices it for you.
It is also worth running git log --stat on your own commits to confirm the file changes attached to each one are what you expect:
git log --stat --author="your-actual-email@example.com"
What to do differently from day one on the next project
The rebuild was the right emergency fix, but the actual lesson is upstream of git commands entirely. A few habits prevent this situation from happening in the first place.
Set your git identity locally per repository, every time, before your first commit, rather than assuming a global config is correct:
git config --local user.name "Your Name"
git config --local user.email "you@example.com"
Never share a single working directory between collaborators for parallel work on different areas of the codebase. Each person should have their own clone, working on their own branch, pushing their own commits, even if you are pair programming in the same room. Shared directories are where identity mixing happens, almost always by accident rather than intent.
Commit in small, single-purpose chunks as you go rather than batching a day's work into one large commit at the end. Small commits are not just good practice for readability, they are also what makes it possible to verify, after the fact, that the pattern of work matches a real development process rather than a reconstruction.
Agree explicitly, before the project starts, on how ownership will be divided and documented, especially if the audit process weighs individual contribution. This conversation feels unnecessary when you trust your collaborator, and it is precisely the kind of thing that is expensive to skip and cheap to have upfront.
The broader point
Git history is not just a backup mechanism or a way to undo mistakes. On any project where individual accountability matters, whether that is a school audit, a job interview asking you to walk through your GitHub, or a workplace performance review, your commit log is a piece of evidence about your actual work, and it is evidence that other people will read literally. A codebase that works perfectly can still tell a false story about who built it, and once you have been on the wrong end of that once, you start treating every git commit as something closer to a signed statement than a convenience command.
Top comments (0)