A single git reset can change everything. In security-focused environments, this is more than a technical hiccup — it's a potential compliance violation. For teams bound by PCI DSS requirements, version control is not just code hygiene. It's an audit trail, a record that must be preserved with precision. Once commits vanish, so does the integrity of that history. And with it, the evidence auditors look for.
Git reset is a powerful tool. It can rewrite commit history, discard changes, and alter the shape of a repository. In many codebases, that's fine — as long as everyone agrees and the risks are known. Under PCI DSS, though, you must keep an accurate and complete record of all changes to system components that store, process, or transmit cardholder data. A force push that follows a git reset --hard can erase commits from the remote repository, erasing that trail forever.
Auditors want proof of every change, who made it, when they made it, and why. PCI DSS requires ensuring that logs and version history are retained and protected from unauthorized changes. git reset and history rewrites directly threaten that requirement. That means your workflow must include guardrails. Ban force pushes to protected branches. Require pull requests or merge requests with code reviews. Enable immutable logging for merges and commits. Use logging systems outside of Git to archive every change before it risks being overwritten.