How should you structure commits for code changes?

• A. Small, focused commits with descriptive messages.
• B. Large, sweeping commits with vague messages.
• C. Commits should be avoided.
• D. Only commit at project milestones.

Answer: (A)

Small, focused commits with descriptive messages help keep the history readable and actionable. When each commit represents a single logical change—such as adding a feature, fixing a bug, or making a small refactor—the diff is easier to review, easier to understand later, and easier to revert if something goes wrong. Clear messages explain not just what changed but why it changed, which is invaluable when you’re looking back at the history or tracking down when a bug was introduced.

To write effective commit messages, use an imperative, concise summary that states what changed, followed by a brief rationale if needed. For example, "Add user login API and tests" or "Fix null pointer in authentication flow and add regression test." Keep the scope small; if a task requires multiple distinct steps, split it into separate commits so each one remains focused.

Large, vague commits muddy intent and make reviews and rollbacks difficult, so they’re not a good approach. And commits aren’t something you should avoid or save only for milestones—regular, well-scoped commits are healthier for the project’s history and maintenance.