Commit Quality

How it works

Commit Quality is one dimension of your AI code review, under the Documentation category. When your solution is hosted in a public GitHub repository, we read your recent commit history and look at how you built the project step by step. We assess three things: your commit messages, how you split the work across commits, and the general hygiene of your repository.

These are practice projects, not production codebases, so we keep the bar realistic. A handful of clear, well-scoped commits is a great result. We don't expect pull requests, branching strategies, signed commits, or CI pipelines here.

What we look at

Each finding is tagged with one of three skills, so you can see exactly where to focus.

Commit messages

A good message describes what changed, and ideally why. Someone reading your history should understand each step without opening the code.

These messages do the job well:

• Add responsive navigation
• Fix card spacing on mobile
• Move button styles into a shared component

These leave the reader guessing:

• update
• fix
• changes
• final
• wip

Commit granularity

Each commit should capture one logical, self-contained piece of work. Committing your whole solution in one go makes it hard to follow your progress or track down where something broke. Committing in small steps as you build gives your history a clear shape and shows how the project came together.

Repo hygiene

Some files don't belong in version control, and we flag the common ones. A committed node_modules folder bloats your repository when those dependencies can be reinstalled from package.json. Committed build output should be rebuilt from source rather than tracked. A committed .env file often holds secrets, so it's safer to git-ignore it and commit a .env.example with placeholder values instead. And if there's no .gitignore at all, adding one keeps dependencies, build output, and editor or OS files out of your repository.

How difficulty changes the bar

We calibrate Commit Quality to the level of the challenge, so the same history is read differently depending on where you are.

• Newbie and Junior: committing in more than one step with real, descriptive messages is a great habit, and it scores well.
• Intermediate: we look for logical commit boundaries, consistent messages, and a clean repository.
• Advanced and Guru: we look for atomic, well-scoped commits with a clear progression. Conventional Commit prefixes like feat:, fix:, and refactor: are a nice touch at these levels. They're never required, and we never penalize you for skipping them.

Committing an entire solution in one go is a fine habit to grow out of when you're starting. At Intermediate and above, it reads as a real gap rather than a missed habit.

When Commit Quality isn't assessed

This dimension currently supports public GitHub repositories. If your solution is hosted somewhere else, or the repository is private, we can't read your commit history, so Commit Quality is marked as not assessed. When that happens, its weight is shared across the other dimensions, so there's no penalty to your overall score.

Improving your score

A few habits make the biggest difference:

• Commit each meaningful piece as you finish it, rather than saving everything for one final commit.
• Write messages that describe the change. "Add mobile menu toggle" tells the reader far more than "update".
• Add a .gitignore before your first commit so dependencies and build files never get tracked in the first place.

New to Git? Our Git and GitHub essentials guide walks through staging, committing, and pushing your work. Once those feel comfortable, focus on committing in small, well-described steps, and your Commit Quality score will rise with the habit.