When re-rebasing a branch, skip (git rebase --skip) any previous post-rebase fixup commits that only touch generated files — they'll conflict against the new base and you'll regenerate fresh anyway.
When a long-lived feature branch has been rebased before, it typically has 'post-rebase fixup' commits at its tip (e.g. 'chore: regenerate openapi-sdk, fix alembic migration chain'). On the next rebase onto a newer master, these fixup commits will always conflict — they patch generated files (OpenAPI SDK, lockfiles, compat manifests) against the OLD master state, which no longer applies.
Use git rebase --skip for these stale fixup commits instead of resolving their conflicts. You'll regenerate everything fresh after the rebase completes anyway. Trying to resolve them wastes time and can introduce subtle errors (e.g. stale schema hashes, outdated SDK types).
Recognition pattern: commit messages like 'chore: post-rebase fixups', 'chore: regenerate openapi-sdk after rebase', or any commit that only touches generated/lockfile artifacts and was created during a previous rebase cycle.