Introduction

A force push rewrites branch history, which means the team usually wants two answers immediately: what changed, and who did it. Local Git can help reconstruct the history movement, but reliable attribution usually comes from the hosting platform’s audit trail rather than from your clone alone.

What Local Git Can Tell You

Your local repository can often show that the remote branch tip changed and what commits were added or removed. If your clone has a reflog for the remote-tracking branch, start there.

git reflog show origin/main --date=iso

If you can identify the old and new tip SHAs, compare them directly:

git log --oneline --graph OLD_SHA..NEW_SHA
git log --oneline --graph NEW_SHA..OLD_SHA
git diff --stat OLD_SHA NEW_SHA

This is good for reconstructing the branch change, but it does not prove who pushed it. Reflog entries are local observations, not authoritative audit records.

Use Server-Side Audit Logs for Attribution

If the repository is hosted on GitHub, GitLab, Bitbucket, or another managed platform, the most reliable attribution source is usually the server’s activity or audit logs.

A practical investigation flow is:

1. identify the branch that moved
2. narrow the time window from CI failures or team reports
3. look for a non-fast-forward push event
4. record the actor, old SHA, new SHA, and timestamp

That is the evidence you want when the question is specifically “who force pushed.”

Do Not Confuse Commit Author With Force-Push Actor

This is one of the most common mistakes in Git incident response. The author shown on commits is not necessarily the person who force pushed the branch. One developer may have authored the commits while another developer rewrote the branch history and pushed it.

That is why commit metadata is useful for reconstructing the history, but not for proving the account that initiated the force push.

Recover Lost History Carefully

Once you know what changed, the next step is often recovery. If the previous branch tip is known, you can restore it with a force push of your own. Use --force-with-lease instead of plain --force so you do not overwrite additional changes unexpectedly.

git checkout main
git reset --hard OLD_SHA
git push --force-with-lease origin main

If the old SHA is not known, ask teammates to inspect their local reflogs. Any clone that fetched the branch before the rewrite may still know the earlier tip.

git reflog --date=iso

That can be enough to recover the lost commits even if the branch itself has already moved on.

Add Logging for Self-Hosted Git

If you run your own Git server, you can improve future investigations by logging non-fast-forward pushes in a server hook.

1#!/usr/bin/env bash
2ref="$1"
3old="$2"
4new="$3"
5
6if ! git merge-base --is-ancestor "$old" "$new"; then
7  echo "$(date -u +%FT%TZ) non-fast-forward ref=$ref old=$old new=$new user=$USER" \
8    >> /var/log/git-force-push.log
9fi
10
11exit 0

This does not just help with incident response. It also gives you a basis for alerts or policy enforcement on protected branches.

Prevent the Problem on Critical Branches

Attribution is useful after the fact, but prevention matters more. For important branches, consider:

1. disabling force pushes entirely
2. requiring pull requests and review
3. requiring passing CI before merge
4. limiting admin bypass to a small group

If a branch must allow force pushes, document when it is allowed and how the team should announce it. That makes later investigation much less chaotic.

Use an Incident Checklist

When a force push is suspected, a short checklist helps:

1. pause further pushes to the affected branch
2. capture the old and new SHAs
3. check audit logs for the actor
4. decide whether to restore history or keep the rewrite
5. communicate the outcome to everyone working on the branch

This prevents a second accidental rewrite while you are still trying to understand the first one.

Common Pitfalls

The most common mistake is assuming the commit author and the force-push actor are the same person. Another is relying on a single developer’s reflog as the full source of truth. Teams also make recovery worse by using plain --force instead of --force-with-lease while investigating.

Summary

• Local Git can show what changed, but hosting-platform logs usually show who force pushed.
• Reflogs are useful for reconstruction and recovery, not for strong attribution by themselves.
• Capture old and new branch tips as early as possible during the investigation.
• Recover history with --force-with-lease when restoration is required.
• Strong branch protection reduces the need for this kind of investigation in the first place.