Git Push — The Force Push That Deleted a Colleague's Commits

Git push is the most dangerous common Git command. A wrong push can overwrite teammates' commits, rewrite published history, and break CI/CD pipelines. The safety mechanisms (--force-with-lease, branch protection, pre-push hooks) are not enabled by default. Every developer has a force-push horror story. This guide covers safe push practices, the anatomy of a force-push disaster, and how to recover when things go wrong.

The Anatomy of a Safe Git Push

Before you type git push, understand what it does: it sends your local commits to a remote repository. A safe push means your changes integrate cleanly without disrupting collaborators. The golden rule: never push to a shared branch without first pulling the latest changes. Use git pull --rebase to replay your commits on top of the remote branch, avoiding merge commits that clutter history. Always verify the remote URL with git remote -v to ensure you're pushing to the correct destination. A common mistake is pushing to the wrong remote (e.g., production instead of staging). Set up remote aliases like origin for your fork and upstream for the main repo. Before pushing, run git log --oneline -5 to review your commits. If you see WIP or debug commits, squash them with git rebase -i. This discipline prevents accidental exposure of half-baked work.

git checkout main
git pull --rebase origin main
git log --oneline -5
# Review commits, then push
git push origin main

Understanding Force Push: When and Why

Force push (git push --force) overwrites the remote branch with your local history. It's destructive: any commits on the remote that you don't have locally are lost. Use it only on private branches or when you've rebased a feature branch and need to update the remote. Never force push to shared branches like main or develop without team agreement. The --force-with-lease option is safer: it checks that your remote-tracking branch matches the remote, preventing accidental overwrite of others' work. For example, if a colleague pushed while you were rebasing, --force-with-lease will reject the push. Always prefer --force-with-lease over --force. In CI/CD pipelines, force push can be used to clean up release branches, but only with strict access controls.

git checkout feature/login-fix
git rebase main
git push --force-with-lease origin feature/login-fix

Recovering from a Force Push Disaster

If you accidentally force-pushed and lost commits, act fast. First, check your local reflog: git reflog shows every HEAD movement. Find the commit before the force push. Create a new branch from that commit: git checkout -b recovery-branch <commit-hash>. Then push this branch to the remote: git push origin recovery-branch. If you don't have the commits locally, check if any teammate has them in their reflog. Ask them to push their version. If the remote has a backup (e.g., GitHub's 'Restore' feature for deleted branches), use that. For repositories with protected branches, force push may be blocked, but if it went through, the reflog is your best friend. Remember: reflog is local and expires after 90 days by default.

git reflog
# Find the commit before force push, e.g., abc1234
git checkout -b recovery abc1234
git push origin recovery
# Notify team to fetch from recovery branch

Preventing Force Push with Branch Protection

Branch protection rules are your first line of defense. On GitHub, GitLab, or Bitbucket, configure rules for critical branches like main, develop, and release/*. Disable force push for these branches. Require pull requests with approvals before merging. Enable status checks (CI, linting) to pass. For teams, use 'Require linear history' to prevent merge commits and enforce rebasing. This ensures that only clean, reviewed code enters production. If a developer needs to force push a feature branch, they can, but the protected branches remain safe. Audit branch protection settings regularly; misconfigurations can lead to incidents.

branches:
  - name: main
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
      required_status_checks:
        contexts:
          - continuous-integration/jenkins
      enforce_admins: true
      restrictions:
        users: []
        teams: []
      allow_force_pushes: false

Using Pre-Push Hooks to Catch Mistakes

Git hooks are scripts that run before certain actions. A pre-push hook can validate branch names, check for sensitive data, or ensure commits are signed. For example, reject pushes to main unless it's a pull request merge. Or block force pushes to branches matching release/*. Hooks are local and not shared by default, but you can distribute them via a script in your repository. Use git config core.hooksPath to point to a versioned hooks directory. A common pre-push hook checks for WIP commits or large files. This catches mistakes before they reach the remote.

#!/bin/bash
# Prevent force push to main
while read local_ref local_sha remote_ref remote_sha
do
  if [[ "$remote_ref" == "refs/heads/main" ]] && [[ "$local_ref" != "refs/heads/main" ]]; then
    echo "ERROR: Direct push to main is not allowed. Use a pull request."
    exit 1
  fi
done
exit 0

Safe Rebasing and Force Push Workflow

Rebasing is common for feature branches, but it rewrites history. After rebasing on main, you must force push the feature branch. The safe workflow: communicate with your team. Before rebasing, ensure no one else is working on that branch. Use git push --force-with-lease after rebase. If someone else has commits on the branch, coordinate to merge their changes first. Alternatively, use git merge instead of rebase to avoid force push. For long-lived feature branches, consider merging main into your branch periodically instead of rebasing. This avoids force push entirely.

git checkout feature/new-api
git fetch origin
git rebase origin/main
git push --force-with-lease origin feature/new-api

Recovering from a Non-Fast-Forward Rejection

A non-fast-forward rejection occurs when your local branch is behind the remote. Git refuses to push because it would lose commits. The solution: pull the latest changes first. Use git pull --rebase to replay your commits on top. If you have merge conflicts, resolve them. After rebase, push normally. If you accidentally force push to resolve this, you might overwrite others' work. Instead, always pull first. If you're in a hurry and force push, you risk disaster. The correct response is to update your local branch, not override the remote.

git pull --rebase origin main
# Resolve conflicts if any
git add .
git rebase --continue
git push origin main

Auditing Push History with Git Log and Reflog

After a push, you may need to audit what was pushed. Use git log --all --oneline --graph to see the full history. For a specific remote, git log origin/main..main shows commits not yet pushed. To see who pushed what, use git reflog show origin/main (if available) or check the remote's audit log (GitHub's 'Push' events). Reflog is local, but you can compare with teammates. If a force push occurred, the reflog shows the old HEAD. Use git fsck --lost-found to find dangling commits. Regularly audit your repository's push history to catch anomalies early.

git log --all --oneline --graph --decorate
# Check reflog for recent changes
git reflog --date=iso | head -10
# Find dangling commits
git fsck --lost-found