git-workflow

Use `git push --force-with-lease --force-if-includes` instead of plain `--force`. The lease alone is disarmed by any `git fetch`, so `--force-if-includes` (git 2.30+) additionally requires your pushed history to contain the remote-tracking tip. Take a backup branch first and verify with `git range-diff`.

Enumerate every unmerged path with `git diff --name-only --diff-filter=U`, then read both sides' history via the operation's ref (MERGE_HEAD, REBASE_HEAD) before editing. Compose both intents where compatible, never use `-X ours` as a shortcut, and run the project's checks before committing.

That is `rerere` replaying a previously recorded resolution into the worktree while the index still marks the path unmerged. Inspect it with `git rerere diff` before committing; `git rerere forget <path>` clears the cache but only `git checkout --merge <path>` restores the markers.

Yes, start at the reflog: `git reflog --date=iso` in the worktree where the work happened, then anchor it with `git branch recover/<slug> <sha>`. `git gc --prune=now` does not delete objects a reflog still references; only `reflog expire` plus `gc` destroys them. Uncommitted work, however, is unrecoverable.

No. `refs/stash` is shared across every worktree of a repository, so parallel agents will pop each other's stash entries. Only HEAD, the index, the working tree, in-progress operation state, and the per-worktree reflog are isolated; commit instead of stashing in parallel setups.

Rebase only your own unpublished topic branch; merge anything others have checked out or built from, since a rebase hands collaborators a history without their commits. Merge also wins when one conflict would otherwise replay through every commit of the series.