The merge looked clean. The history was a lie.

Git rebase can rewrite commit history, making code reviews harder and security audits riskier if not handled with discipline. A rebase changes commit SHA values and adjusts the timeline as if certain changes happened in a different order. This is powerful for keeping a project history tidy, but it also opens the door to obscured changes—especially if rebased code is pushed without a clear review trail.

A security review after a rebase isn’t optional. It’s a line of defense against hidden code injections, silent permission changes, or subtle shifts in dependencies. Rebasing can make malicious commits blend in with legitimate changes. Without strong checks, you rely on trust rather than verification.

To run an effective Git rebase security review, start by inspecting every commit in the rebased branch against the original. Use git log --patch to view all diffs. Compare commit hashes before and after rebase to confirm no untracked changes slipped in. Pay attention to files that change outside expected scope—especially configuration and access control files.

Leverage Git’s built-in tools for forensic inspection. git diff --stat <old-base> <new-base> can quickly reveal structural changes. git blame helps you trace who introduced each line. Run automated scans for secrets and known vulnerability patterns before and after rebase to catch high-risk changes that might evade manual review.

Lock down the workflow to require pull requests for rebased branches, even if history looks clean. Enforce branch protection rules to block direct pushes after a rebase. Maintain a signed commit policy so that any rewritten history still carries cryptographic proof of authorship.

Document the rebase security review process. Store reports alongside repository metadata so there’s a permanent record for auditors. Treat every rebase like a potential attack vector, not just a tool for convenience. When dealing with sensitive or production code, the review must be exhaustive.

Rebasing sharpens the code history. A good security review is the grindstone that makes it safe.

Run the workflow with zero setup using hoop.dev and see your Git rebase security review live in minutes.