git commit: полное руководство по фиксации изменений в Git

Команда git commit создаёт снимок состояния вашего проекта в конкретный момент времени. Это самая важная операция в Git — именно коммиты составляют историю проекта. В этой статье разберём всё: базовое использование, параметры, написание хороших сообщений, типы коммитов и типичные ошибки.

Перед коммитом файлы нужно добавить в индекс командой git add. Подробнее об этом — в статье «git add: добавление файлов в staging area».

Базовое использование #

Простейший коммит:

git commit -m "Добавлена новая функция авторизации"

Флаг -m позволяет указать сообщение прямо в командной строке. Без него Git откроет текстовый редактор для ввода сообщения. Это удобно для многострочных описаний.

Перед коммитом проверьте, что именно будет включено:

git status        # Список изменённых файлов
git diff --staged # Точные изменения, готовые к коммиту

Параметры git commit #

-m (message): сообщение коммита #

git commit -m "Сообщение коммита"

-a (all): добавить и закоммитить изменённые файлы #

git commit -a -m "Сообщение"
# или сокращённо
git commit -am "Сообщение"

Флаг -a автоматически добавляет все изменённые (но не новые!) файлы в индекс перед коммитом. Удобно, но не даёт той гибкости, что git add + git commit.

–amend: изменить последний коммит #

# Изменить сообщение последнего коммита
git commit --amend -m "Новое, исправленное сообщение"

# Добавить файл в последний коммит без изменения сообщения
git add forgotten_file.js
git commit --amend --no-edit

Важно: --amend переписывает историю. Не используйте его для коммитов, которые уже запушены в общую ветку.

–allow-empty: создать пустой коммит #

git commit --allow-empty -m "ci: запустить pipeline"

Полезно для ручного запуска CI/CD без реальных изменений кода.

–no-verify: пропустить хуки #

git commit --no-verify -m "Сообщение"

Пропускает pre-commit и commit-msg хуки. Используйте только в исключительных случаях — хуки обычно существуют не просто так.

-S (gpgsign): подписать коммит GPG-ключом #

git commit -S -m "Подписанный коммит"

# Автоматическая подпись для всех коммитов
git config --global commit.gpgsign true

Подпись подтверждает, что коммит действительно создали вы.

Структура сообщения коммита #

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

Формула #

<тип>: <краткое описание> (до 50 символов)

<подробное объяснение — что сделано и почему>
(до 72 символов на строке)

<ссылки на задачи, связанные PR>

Примеры плохих сообщений #

git commit -m "обновление"       # Что именно обновили?
git commit -m "фиксы"            # Какие фиксы?
git commit -m "работа"           # Абсолютно бесполезно
git commit -m "."                # Хуже некуда

Примеры хороших сообщений #

# Краткое, но информативное
git commit -m "fix: исправлена валидация email в форме регистрации"

# С подробным описанием
git commit -m "feat: добавлена OAuth2 авторизация через Google

- Интегрирован Google OAuth2 SDK
- Создан flow авторизации с управлением токенами
- Добавлена обработка refresh token
- Написаны тесты для эндпоинтов авторизации

Closes #456"

Типы коммитов (Conventional Commits) #

Conventional Commits — это соглашение о форматировании сообщений коммитов. Оно упрощает чтение истории, помогает генерировать CHANGELOG и работает с инструментами семантического версионирования.

feat:      новая функция для пользователя
fix:       исправление ошибки
docs:      изменения в документации
style:     форматирование, без изменений функционала (пробелы, точки с запятой)
refactor:  рефакторинг без новых функций и без исправлений
perf:      изменения для улучшения производительности
test:      добавление или изменение тестов
build:     изменения в системе сборки или зависимостях
ci:        изменения конфигурации CI/CD
chore:     обновление зависимостей, конфигурации и т.д.
revert:    откат предыдущего коммита

Примеры Conventional Commits #

git commit -m "feat: добавлена возможность экспорта в CSV"
git commit -m "fix: исправлена критическая ошибка при загрузке файлов >100MB"
git commit -m "docs: обновлена документация API для эндпоинта /users"
git commit -m "refactor: упрощены вспомогательные функции форматирования"
git commit -m "test: добавлены unit-тесты для модуля авторизации"
git commit -m "chore: обновлены зависимости до последних версий"
git commit -m "perf: оптимизированы SQL-запросы для списка заказов"

Breaking changes #

Если изменение нарушает обратную совместимость, добавьте ! или BREAKING CHANGE в тело:

git commit -m "feat!: изменён формат ответа API /users

BREAKING CHANGE: поле 'name' разделено на 'firstName' и 'lastName'."

Многострочные сообщения в командной строке #

git commit -m "feat: новый экспорт данных

Добавлена возможность экспортировать данные в форматах:
- CSV с настраиваемыми разделителями
- Excel (.xlsx) с форматированием
- JSON с возможностью выбора полей

Refs: #789"

Редактирование сообщения в редакторе #

Если не использовать -m, откроется текстовый редактор:

git commit

В файле будет закомментированная информация о статусе. Напишите сообщение в начале файла, сохраните и закройте редактор. Git создаст коммит.

Чтобы выбрать редактор:

git config --global core.editor "code --wait"  # VS Code
git config --global core.editor "nano"         # Nano
git config --global core.editor "vim"          # Vim

Просмотр истории коммитов #

# Полный журнал
git log

# Компактный формат (одна строка на коммит)
git log --oneline

# С информацией о файлах
git log --stat

# С diff каждого коммита
git log -p

# Последние N коммитов
git log -5

# Красивый граф веток
git log --graph --oneline --all

# Коммиты определённого автора
git log --author="Иван Петров"

# Коммиты за период
git log --since="2024-01-01" --until="2024-12-31"

Изменение и отмена коммитов #

Изменить последний коммит #

# Добавить файл и обновить коммит
git add forgotten_file.js
git commit --amend --no-edit

# Изменить сообщение
git commit --amend -m "Исправленное сообщение"

Отменить последний коммит (сохранить изменения) #

git reset HEAD~1
# Коммит удалён, изменения остались в рабочей директории

Отменить последний коммит (удалить изменения) #

git reset --hard HEAD~1
# Коммит удалён, изменения потеряны — осторожно!

Создать коммит, отменяющий предыдущий (безопасно) #

git revert <commit-hash>
# История сохранится, новый коммит отменяет старый
# Безопасно для уже запушенных коммитов

Лучшие практики #

Несколько правил для хорошей истории коммитов:

Первая строка — до 50 символов. Это краткое описание. GitHub обрезает длинные заголовки.

Вторая строка — пустая. Это разделитель между заголовком и телом.

Строки тела — до 72 символов. Традиционное ограничение для удобного отображения.

Используйте повелительное наклонение. «Добавить» вместо «Добавлено», «Исправить» вместо «Исправлено». Это стандарт для Git-проектов.

Объясняйте ЗАЧЕМ, не КАК. «КАК» видно из diff. «ЗАЧЕМ» — нет.

Один коммит — одна логическая задача. Не смешивайте рефакторинг и новые функции в одном коммите.

Коммитьте часто. Маленькие частые коммиты лучше, чем большие редкие.

Типичные ошибки #

Пустое или бессмысленное сообщение:

git commit -m ""      # Git запрещает пустое сообщение
git commit -m "wip"   # What exactly is in progress?
git commit -m "fix"   # Fix what?

Слишком большой коммит: один коммит с изменениями в 50 файлах по разным задачам невозможно осмысленно описать. Разделяйте на маленькие логичные части.

Секреты в коммите:

git commit -m "Add config"  # А в файле есть API_KEY=sk_live_...

После того как коммит создан и запушен, ключ скомпрометирован. Используйте .gitignore и переменные окружения.

Злоупотребление –amend: изменение уже запушенного коммита переписывает историю и создаёт проблемы для всей команды.

Практические примеры #

# Пример 1: простой коммит с одним файлом
git add feature.js
git commit -m "feat: add user authentication"

# Пример 2: коммит с подробным описанием
git add -A
git commit -m "feat: implement OAuth2 authentication

- Added Google OAuth2 integration
- Created login flow with token management
- Added refresh token handling
- Tests added for auth endpoints

Closes #456"

# Пример 3: исправление ошибки в последнем коммите
git add forgotten_file.js
git commit --amend --no-edit

# Пример 4: отмена последнего коммита с сохранением изменений
git reset HEAD~1
git status
# Изменения остались, коммит удалён

# Пример 5: просмотр что будет закоммичено
git diff --staged
git commit -m "refactor: simplify authentication logic"

Часто задаваемые вопросы #

Что значит «commit is signed»? Коммит подписан GPG-ключом. Это гарантирует авторство — GitHub показывает специальный значок «Verified» рядом с таким коммитом.

Можно ли изменить коммит после push? Можно (--amend + git push --force), но это опасно в общих ветках: вы переписываете историю, которую уже скачали другие. Используйте git revert вместо этого.

Я закоммитил в неправильную ветку. Что делать? Используйте git cherry-pick чтобы скопировать коммит в нужную ветку, затем git reset чтобы убрать его из текущей.

Как найти коммит, который сломал код? Используйте git bisect — бинарный поиск по истории коммитов. Укажите «плохой» и «хороший» коммит, Git поможет найти проблемный.

Сколько коммитов делать в день? Нет правила. Коммитьте каждый раз, когда закончена логическая часть работы: исправлена ошибка, реализована функция, написан тест. Лучше 10 маленьких коммитов, чем один гигантский.

Заключение #

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

Используйте Conventional Commits для структурированных проектов, пишите осмысленные описания и коммитьте часто с небольшими изменениями. Это основа профессиональной работы с Git.

По теме #

• Conventional Commits: типы feat, fix, chore и другие
• git commit –amend
• Отмена последнего коммита
• Сообщение merge-коммита