Skip to content

Anti-Primer: Git

Everything that can go wrong, will — and in this story, it does.

The Setup

A developer is preparing a major release branch while simultaneously cleaning up old feature branches. The repo has 3 years of history and the team uses a rebase workflow. It is late Friday and the release must ship Monday.

The Timeline

Hour 0: Force Push to Shared Branch

Runs git push --force on the release branch after a local rebase. The deadline was looming, and this seemed like the fastest path forward. But the result is three teammates lose their commits that were pushed after the rebase point.

Footgun #1: Force Push to Shared Branch — runs git push --force on the release branch after a local rebase, leading to three teammates lose their commits that were pushed after the rebase point.

Nobody notices yet. The engineer moves on to the next task.

Hour 1: Rebase Public History

Rebases a branch that 4 other people are working on. Under time pressure, the team chose speed over caution. But the result is everyone gets merge conflicts on their next pull; two spend hours untangling.

Footgun #2: Rebase Public History — rebases a branch that 4 other people are working on, leading to everyone gets merge conflicts on their next pull; two spend hours untangling.

The first mistake is still invisible, making the next shortcut feel justified.

Hour 2: Reset --hard Without Stash

Runs git reset --hard HEAD~5 to 'clean up' but forgot about uncommitted work. Nobody pushed back because the shortcut looked harmless in the moment. But the result is two days of uncommitted changes are permanently lost.

Footgun #3: Reset --hard Without Stash — runs git reset --hard HEAD~5 to 'clean up' but forgot about uncommitted work, leading to two days of uncommitted changes are permanently lost.

Pressure is mounting. The team is behind schedule and cutting more corners.

Hour 3: Committing Secrets

Adds .env with database credentials in a hurried commit. The team had gotten away with similar shortcuts before, so nobody raised a flag. But the result is credentials are in git history even after the file is deleted; requires credential rotation.

Footgun #4: Committing Secrets — adds .env with database credentials in a hurried commit, leading to credentials are in git history even after the file is deleted; requires credential rotation.

By hour 3, the compounding failures have reached critical mass. Pages fire. The war room fills up. The team scrambles to understand what went wrong while the system burns.

The Postmortem

Root Cause Chain

# Mistake Consequence Could Have Been Prevented By
1 Force Push to Shared Branch Three teammates lose their commits that were pushed after the rebase point Primer: Use --force-with-lease and communicate before force pushing
2 Rebase Public History Everyone gets merge conflicts on their next pull; two spend hours untangling Primer: Never rebase shared branches; merge instead
3 Reset --hard Without Stash Two days of uncommitted changes are permanently lost Primer: Stash or commit before any destructive operation
4 Committing Secrets Credentials are in git history even after the file is deleted; requires credential rotation Primer: .gitignore from day one and pre-commit hooks for secret scanning

Damage Report

  • Downtime: 2-4 hours of degraded or unavailable service
  • Data loss: Potential, depending on the failure mode and backup state
  • Customer impact: Visible errors, degraded performance, or complete outage for affected users
  • Engineering time to remediate: 8-16 engineer-hours across incident response and follow-up
  • Reputation cost: Internal trust erosion; possible external customer-facing apology

What the Primer Teaches

  • Footgun #1: If the engineer had read the primer, section on force push to shared branch, they would have learned: Use --force-with-lease and communicate before force pushing.
  • Footgun #2: If the engineer had read the primer, section on rebase public history, they would have learned: Never rebase shared branches; merge instead.
  • Footgun #3: If the engineer had read the primer, section on reset --hard without stash, they would have learned: Stash or commit before any destructive operation.
  • Footgun #4: If the engineer had read the primer, section on committing secrets, they would have learned: .gitignore from day one and pre-commit hooks for secret scanning.

Cross-References