Пишем коммиты и Pull Request на английском

Коммит и PR — твоя визитка как инженера. По ним судят о тебе раньше, чем по коду. И почти всегда они на английском.

A commit message is a love letter to your future self. — git folklore

Хорошее сообщение коммита и понятное описание PR экономят часы команде и тебе самому через полгода. Здесь действуют устоявшиеся конвенции, в том числе грамматические: например, коммиты пишут в повелительном наклонении. Разберём, как делать это правильно и без типичных ошибок.

Конвенция сообщений коммитов

Принятый стандарт — type: imperative summary. Главное правило: используй повелительное наклонение (что коммит делает с кодом), а не прошедшее время.

Type	Когда	Пример
feat	новая функциональность	feat: add user search
fix	исправление бага	fix: handle empty cart
refactor	рефакторинг без смены поведения	refactor: extract auth helper
docs	документация	docs: update README install steps
test	тесты	test: add edge cases for parser
chore	рутина, конфиги	chore: bump dependencies

Imperative mood: правильно и неправильно

Неправильно	Правильно (imperative)
fixed login bug	fix login bug
added new endpoint	add new endpoint
changing the config	change the config
updates the docs	update the docs

Подсказка: коммит должен дополнять фразу «If applied, this commit will ___». «If applied, this commit will fix login bug» — звучит верно.

Шаблон описания Pull Request

## What
Add retry logic to the API client.

## Why
Requests sometimes fail on flaky network; this reduces
manual retries and improves reliability.

## How
- Wrap fetch in a retry helper (3 attempts, backoff)
- Add unit tests for the retry path

## Notes
- Configurable via MAX_RETRIES env var
- No breaking changes

Структура What / Why / How / Notes универсальна: ревьюер сразу видит, что сделано, зачем и как, и где обратить внимание.

Полезные фразы для PR

This PR adds support for X.            — Этот PR добавляет поддержку X.
This fixes the issue where …          — Это исправляет проблему, когда …
Open to feedback on the approach.      — Открыт к фидбеку по подходу.
Marking as draft until tests pass.     — Помечаю как черновик, пока не пройдут тесты.

Частые ошибки рус-говорящих

Прошедшее время в коммитах. Конвенция требует imperative: fix, а не fixed. Это не мелочь, по этому видно знание стандартов.
Описание PR «обновил код». Ревьюер не знает контекста. Всегда отвечай на «что» и «зачем», а не только «что».
Слишком длинный заголовок коммита. Держи summary в пределах ~50 символов, детали — в теле коммита.

Чек-лист перед PR

Заголовки коммитов в imperative и с типом (feat/fix/...)?
В описании PR есть What и Why, а не только список файлов?
Отмечены ли breaking changes, если они есть?
Заголовок коммита короткий и читаемый?

Маленькие PR и понятные заголовки

Культура PR в англоязычных командах ценит маленькие пулл-реквесты: их быстрее ревьюить и безопаснее мерджить. Огромный PR на 50 файлов вызывает у ревьюера фразу «could you split this up?» — «можешь разбить на части?». Привыкай дробить работу и описывать каждый кусок отдельно.

Фраза ревьюера	Перевод	Что делать
Could you split this up?	Можешь разбить?	раздели на несколько PR
Can you rebase on main?	Сделай rebase на main	обнови ветку
Please squash the commits.	Схлопни коммиты	объедини в один
Add a test for this.	Добавь тест	покрой изменение тестом
Needs a changelog entry.	Нужна запись в changelog	опиши изменение

Заголовок PR — это то, что увидят в списке и в истории. Делай его конкретным: не «Update», а «Add retry logic to API client». Хороший заголовок отвечает на вопрос «что изменится, если это смерджить» одной короткой фразой в повелительном наклонении.

Шпаргалка по PR

Ключ	Смысл	Где встречается
imperative	fix, не fixed	if applied, will fix…
type:	feat/fix/docs…	категория коммита
What / Why	что и зачем	обязательно в PR
breaking	пометить	если ломает совместимость

Коммит и PR — твоя витрина. Imperative-заголовок с типом и описание What/Why читаются как знак опытного инженера ещё до самого кода.

Итоги

Коммиты и PR — профессиональная витрина, и почти всегда на английском. Пиши коммиты в повелительном наклонении (fix, а не fixed) с типом, проверяя себя фразой «If applied, this commit will ___». В PR раскрывай What / Why / How, отмечай breaking changes. Эти конвенции читаются как знак опытного инженера.