git-commit-practices

Atomic commit messages should be clear, concise, and imperative. Use single-purpose messages that describe what changed and why (e.g., 'Add user authentication API endpoint' rather than 'Update code'). This makes code reviews and debugging easier while keeping your repository history readable.

Atomic commits are small, logical, single-purpose changes that capture one feature, bug fix, refactor, or documentation update. Atomic commits enable safer reverts, clearer project history, and simpler code reviews by isolating each change so reviewers understand intent and impact immediately.

Commit frequently after each logical step—not the entire feature at once. Breaking work into incremental commits (e.g., 'Add data model', 'Add API endpoint', 'Add validation') makes changes easier to review, reverting broken logic simpler, and tracking what changed clearer.

Always use feature branches for development work. Master or main should contain only stable, reviewed code. Feature branches keep experimental commits isolated, enable clean history when merged, and allow multiple team members to work without disruption.

Enforce atomic commits by making single-purpose changes frequently, write descriptive messages, and use feature branches. This prevents massive combined commits, keeps the repository navigable during code review and debugging, and enables safe, surgical reverts when needed.

Yes, using interactive rebase or ammending before pushing. However, after pushing to shared branches, rewriting history disrupts teammates. Instead, adopt atomic commit practices going forward and open a new pull request with clean commits to maintain team workflow integrity.