Если вы только начали работать с Git, вопрос подсчёта коммитов после слияния Pull Request (PR) может показаться запутанным. Представьте: вы сделали 20 правок в отдельной ветке, отправили их на проверку, а потом ваш PR успешно приняли. Но как это отразится в истории репозитория? Будет ли это 20 отдельных записей или одна? Всё зависит от метода слияния, который выберет мейнтейнер. Давайте разбираться, как это работает на практике.
Почему метод слияния решает всё
Git даёт несколько вариантов объединения веток, и каждый из них влияет на историю коммитов по-разному. Вот три основных сценария:
1. Обычный merge (слияние):
git merge feature-branch --no-ffЗдесь все 20 коммитов сохранятся в истории как есть. Вы останетесь автором (author) и коммиттером (committer) для каждой правки. Дополнительно появится отдельный коммит слияния — его автором будет тот, кто выполнил мерж. Этот метод чаще используют в проектах, где важно отслеживать историю изменений детально.
2. Rebase (перебазирование):
git rebase mainВаши коммиты будут «переписаны» поверх текущей версии основной ветки. Авторство (author) сохранится за вами, но коммиттером (committer) станет тот, кто выполнил rebase. Это может запутать, если вы смотрите на метаданные через git log, но в целом история останется линейной и чистой (без лишних merge-коммитов).
3. Squash merge (объединение в один коммит):
git merge --squash feature-branchВсе 20 правок «склеятся» в один коммит. Вы будете указаны как автор, но в истории репозитория появится только эта единая запись. Удобно, если PR содержал много промежуточных правок вроде «исправил опечатку» или «добавил комментарий», которые не нужны в основной ветке.
Кстати, если вы работаете на GitHub, выбор метода часто зависит от настроек репозитория. Например, в некоторых проектах squash merge включён по умолчанию для всех PR.
Как не запутаться: советы новичкам
Если вы хотите, чтобы ваши коммиты сохранились в истории:
- Перед созданием PR обсудите с мейнтейнером, какой метод слияния он планирует использовать.
- Избегайте множества мелких коммитов в одной ветке – их могут посчитать «шумом» и применить squash.
- Проверьте метаданные после слияния через
git log --pretty=format:"%h %an %cn %s"– это покажет, кто автор и коммиттер.
Распространённая ошибка: считать, что количество коммитов в PR автоматически влияет на ваш вклад в репозиторий. На самом деле, некоторые проекты учитывают только количество принятых PR, а не отдельных правок. Тут всё зависит от политики конкретного сообщества.
Пример: В опенсорс-проектах часто ценят атомарные коммиты (каждая правка решает одну задачу), но для этого нужен обычный merge. Если же PR содержит эксперименты или черновые наброски, squash поможет сохранить историю чистой.
И ещё один нюанс: даже при squash merge ваш вклад не пропадёт – изменения попадут в основную ветку, но будут «упакованы» в один коммит. А вот если мейнтейнер решит вручную скопировать ваш код без использования Git-методов, тогда правки вообще не отобразятся в истории. Но это крайне редкий случай.
Итог: Количество коммитов, которые «засчитаются» в репозитории, зависит не от вас, а от workflow проекта. Если для вас принципиально сохранить историю правок, уточните правила работы с PR заранее – это избавит от неожиданностей после мержа.