Что делает коммит и сообщение коммита хорошими?

Question

Accepted Answer

Хорошие коммиты **сосредоточены** (одно логическое изменение) с **понятными сообщениями**, которые объясняют, что изменилось и почему. Хорошо оформленные коммиты и сообщения делают историю проекта читаемой, полезной для понимания изменений, отладки и сотрудничества.

## Хорошие сообщения коммитов

```text
GOOD message structure:
  Short summary line (~50 chars, imperative mood, capitalized, no period)
  <blank line>
  Optional body: explain WHAT and WHY (not how — the code shows how),
  wrap at ~72 chars. Reference issues if relevant.
```

```text
✅ GOOD:
  Add user email validation to registration form

Validate email format before submission to prevent invalid
  accounts. Fixes #142.

❌ BAD:
  "fixed stuff", "update", "asdf", "changes", "wip"
  → vague, uninformative — useless when reviewing history later
```

## Соглашение об императивном наклонении

```text
Write the summary as a COMMAND/instruction (imperative):
  ✓ "Add feature", "Fix bug", "Update docs", "Remove dead code"
  ✗ "Added feature", "Fixes bug", "Updating docs"
→ Convention: it reads as "this commit will [Add feature]" (matches Git's own messages).
```

## Хорошие коммиты: атомарные и сосредоточенные

```text
✓ ATOMIC — each commit is ONE logical change (not many unrelated changes lumped together)
✓ Focused — "Add login" and "Fix typo" are SEPARATE commits, not one
✓ Working — ideally each commit leaves the code in a working state
Why: focused commits are easier to REVIEW, REVERT (undo one change cleanly),
  understand, and bisect (find which commit introduced a bug).
```

## Conventional Commits (популярный стандарт)

```text
type(scope): description    → feat: add login | fix: handle null | docs: update README
  types: feat, fix, docs, refactor, test, chore, etc.
→ Enables automated changelogs/versioning; widely adopted in many projects.
```

## Почему это важно

Понимание того, что делает коммиты и сообщения коммитов хорошими, ценно для **создания читаемой, полезной истории проекта**, поэтому это важное практическое знание, которое значительно влияет на сотрудничество и поддерживаемость. **Хорошие сообщения коммитов** важны, потому что история коммитов — это решающая форма документации — понятные сообщения (краткое резюме, объясняющее *что* изменилось, с телом, объясняющим *почему*, когда это необходимо) делают возможным понимание того, как и почему код эволюционировал, что неоценимо при просмотре истории, отладке (понимании, почему было сделано изменение) или адаптации новых людей.

Неясные сообщения ("fixed stuff", "update", "wip") делают историю бесполезной, делая невозможным понимание изменений позже — это реальная стоимость.

**Соглашение об императивном наклонении** ("Add feature" вместо "Added feature") — это широко применяемый стандарт, стоящий изучения. **Хорошие коммиты, являющиеся атомарными и сосредоточенными** (каждый коммит одно логическое изменение, а не много несвязанных изменений вместе) равно важны: сосредоточенные коммиты намного легче **проверять** (рецензенты понимают одно изменение), **откатывать** (отмена одного изменения чисто без влияния на другие), понимать и **бисектировать** (найти, какой коммит внес ошибку) — таким образом, структура коммита напрямую влияет на то, насколько полезна история для отладки и сотрудничества.

Знание о **Conventional Commits** (стандарт `type(scope): description`, позволяющий автоматизировать журналы изменений и версионирование) ценно, так как он широко принят.

Поскольку история коммитов — это важная документация, а хорошие коммиты и сообщения делают её читаемой и полезной (для понимания, проверки, отладки и сотрудничества), в то время как плохие делают её бесполезной, и поскольку создание сосредоточенных коммитов с понятными сообщениями — это признак профессиональной практики Git, понимание того, что делает коммиты и сообщения коммитов хорошими, — это ценное, практически релевантное знание для эффективного сотрудничества и поддерживаемой истории — навык, который отличает вдумчивых разработчиков и значительно улучшает долгосрочную полезность проекта и рабочий процесс команды.