Tidy First

Separate structural changes from behavioral changes by committing tidying and refactoring first—moving, renaming, and reorganizing code without altering behavior—then committing feature additions or bug fixes in a second, purely behavioral commit. This approach keeps commits pure, focused, and auditable.

Structure commits by tidying first, then implementing. Start by making all structural changes to a module—reorganizing helpers, moving code, refactoring—and commit those changes. Next, implement the feature or fix and commit the behavioral changes separately, ensuring each commit has a single, clear purpose.

Separating refactoring from feature commits improves code review clarity, enables easier blame and bisect operations, and prevents mixing concerns that obscure intent. Pure structural commits document reorganization intent independently from behavioral logic, making history auditable and easier to understand.

Yes, this approach applies to feature development, refactoring, and bug fixes. For any change, tidy the affected code structure first—rename, move, reorganize—commit those structural changes, then implement the fix or feature and commit the behavioral changes separately.

Validate that structural commits contain only reorganization with no behavior changes, and that behavioral commits are isolated to feature or fix logic. Use provided templates and rules to confirm each commit is pure, then validate the full sequence together before merging to ensure correctness.

Ordering structural commits before behavioral commits in version control creates a clean audit trail where refactoring changes are isolated and reviewable separately. This ordering simplifies blame tracking, enables targeted git bisect operations, and clarifies why code was reorganized independent of what it now does.