The commit history looked clean. Too clean.
Git rebase can rewrite history with precision, but it can also be used for subtle social engineering inside engineering teams. The power to reorder, squash, and edit commits is not just a technical tool—it can shape how work is perceived, how blame is assigned, and how credit is distributed. In the wrong hands, it becomes a lever for manipulation.
A developer with deep Git knowledge can rebase a branch to remove traces of mistakes or insert changes under a different author. This isn’t about fixing messy code—it’s about altering narrative control. Alter commit dates, change authorship, reorganize sequences, and you distort the timeline. This can make performance reviews skewed, mislead code audits, and mask security issues.
Social engineering in this context is not phishing emails—it’s about influencing team decisions and trust through version control mechanics. A pull request emerging from a rebased branch may hide who actually wrote core logic, or make it appear that certain work was done earlier or more efficiently than it really was. In distributed teams, where Git is gospel, the rebase becomes a subtle but potent means of persuasion.