refactor-git-plan

Plan refactoring commits by creating one atomic commit per major change—rename, extraction, or move. Use commit message format refactor(<scope>): <action>, document what changed and why, include risk level (low/medium/high), and test status (passing/added/updated). This keeps refactors reviewable and reversible across branches.

Follow the refactor/<scope>-<action> naming pattern for refactor branches. Scope identifies the component or module being refactored, and action describes the refactoring type—extract, rename, move, or pattern application. This standardizes branch strategy and signals intent clearly in merge workflows.

Plan your refactoring by defining scope, breaking changes into atomic commits, establishing pre-flight and post-commit safety checks, and documenting rollback guidance. Use scoped branches, granular commits with standardized messages, and test validation at each step to ensure changes remain reviewable and reversible.

Run pre-flight checks before refactoring to verify the baseline state. After each commit, validate that tests pass or document what was added or updated. Include explicit risk assessment (low/medium/high) in commit messages and maintain rollback guidance so merges can be safely reverted if issues arise.

Yes. Extract services by planning commits for each extraction phase—interface definition, implementation, migration, and cleanup. Use refactor/<service>-extract branch naming, commit each phase separately, run tests after each step, and document risk and test status in commit messages for safe, reviewable extraction.

Create dedicated commits for file moves and renames using refactor/<scope>-move or refactor/<scope>-rename branches. Commit the structural change separately from content modifications, document what changed and why, include test validation status, and mark risk level so reviewers understand the refactoring scope.