You rebase a feature branch onto an updated main and resolve the conflicts, but the environment blocks `git push --force`, `git push --force-with-lease`, and `git reset --hard` via permission rules or branch protection. The local branch has now diverged from its remote tracking branch, so an ordinary push is rejected as non-fast-forward. The existing PR still shows the pre-rebase commits and reports CONFLICTING, and every obvious escape hatch is denied. It looks like you must either abandon the rebase or get the restriction lifted.

When a pre-commit hook fails (linting error, formatting issue, test failure), the git commit does NOT happen — it's aborted. A common mistake is to fix the issue and then run 'git commit --amend', thinking you're retrying the failed commit. But --amend doesn't retry — it modifies the PREVIOUS successful commit. If that previous commit was from yesterday's feature work, amending would: (1) merge today's unrelated changes into yesterday's commit, (2) lose yesterday's original commit message, (3) create a confusing git history where one commit contains changes from two different features, and (4) if already pushed, would require a force-push to fix. This is especially dangerous for AI coding agents that automate git operations.

Users sometimes ask AI coding assistants to 'clean up', 'reset', 'start fresh', 'remove old files', or 'reorganize the project'. These requests are ambiguous — the user might mean 'move unused files' or they might mean 'permanently delete everything I don't currently need.' Deletion is irreversible (unless there's a backup or git history). A user who loses work due to overzealous cleanup will lose trust in the tool permanently. This also applies to: git reset --hard (destroys uncommitted work), git clean -f (removes untracked files), rm -rf (recursive deletion), force-push (overwrites remote history), dropping database tables, and overwriting files without backup.