Для чего нужны коммиты?

Коммиты в Git - отслеживание истории изменений

Коммит — это снимок состояния проекта в определённый момент времени. Это основной способ сохранения и отслеживания изменений кода в системе контроля версий Git.

Основная проблема, которую решают коммиты

Без контроля версий:

project_final.zip
project_final_v2.zip
project_final_v2_real.zip
project_final_v2_real_working.zip
project_final_v2_real_working_FIX.zip

С Git коммитами:

• feat: добавил аутентификацию (abc123)
• fix: исправил баг с кэшем (def456)
• docs: обновил README (ghi789)
• refactor: переделал API клиент (jkl012)

Зачем нужны коммиты

1. История изменений:

git log
# commit abc123 - добавил аутентификацию
# commit def456 - исправил баг
# commit ghi789 - начальный коммит

# Видно, КТО и КОГДА сделал что

2. Откат на предыдущую версию:

# Если что-то сломалось
git revert abc123
# или
git reset --hard def456

3. Понимание, почему была сделана та или иная строка кода:

git blame src/auth.js
# показывает, в каком коммите каждая строка добавлена

4. Коллаборация в команде:

# Видно, кто и когда внёс изменение
# Можно обсудить изменения через Pull Request

Структура коммита

Что содержит коммит:

{
  "hash": "abc123def456",           // Уникальный идентификатор
  "author": "John Doe",             // Кто сделал
  "email": "john@example.com",      // Email автора
  "date": "2026-04-02 10:30:00",   // Когда сделал
  "message": "feat: добавил форму", // Что сделал
  "files_changed": 5,               // Сколько файлов изменилось
  "insertions": 120,                // Строк добавлено
  "deletions": 45                   // Строк удалено
}

Как создать коммит

Основной процесс:

# 1. Изменил файлы
echo "новый код" > src/app.js

# 2. Посмотреть, что изменилось
git status
# На output: modified: src/app.js

# 3. Добавить файлы в staging area
git add src/app.js
# или всё разом
git add .

# 4. Создать коммит с сообщением
git commit -m "feat: добавил новую функцию"

# 5. Отправить на сервер
git push origin main

Пошаговый пример:

# Создаю новый файл
touch src/utils.js
echo "export const sum = (a, b) => a + b;" > src/utils.js

# Проверяю статус
git status
# Untracked files:
#   src/utils.js

# Добавляю в индекс
git add src/utils.js

# Проверяю ещё раз
git status
# Changes to be committed:
#   new file: src/utils.js

# Создаю коммит
git commit -m "feat: добавил утилиту sum"
# [main abc123] feat: добавил утилиту sum
#  1 file changed, 1 insertion(+)

# Отправляю
git push origin main

Хорошее сообщение коммита

Плохое сообщение:

git commit -m "fix"        # Что исправил?
git commit -m "updates"    # Какие обновления?
git commit -m "wip"        # Work in progress - не финально!

Хорошее сообщение (Conventional Commits):

# Формат: <type>: <description>

git commit -m "feat: добавил форму входа"
git commit -m "fix: исправил баг с кэшем на 301 строке"
git commit -m "docs: обновил README с инструкциями"
git commit -m "refactor: переделал API клиент"
git commit -m "test: добавил тесты для утилит"
git commit -m "chore: обновил зависимости"

Типы коммитов:

• feat: - новая функция
• fix: - исправление ошибки
• docs: - изменение документации
• style: - изменения форматирования кода
• refactor: - переделка кода без новых функций
• test: - добавление тестов
• chore: - технические изменения (зависимости, конфиг)

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

Базовые команды:

# Полная история
git log
# commit abc123
# Author: John Doe <john@example.com>
# Date: Wed Apr 2 10:30:00 2026
# feat: добавил форму

# Одна строка на коммит
git log --oneline
# abc123 feat: добавил форму
# def456 fix: исправил баг
# ghi789 docs: обновил README

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

# История одного файла
git log -- src/app.js

# Кто когда что менял
git blame src/app.js
# abc123 (John Doe 2026-04-02) const x = 1;

Работа с коммитами

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

git reset --soft HEAD~1
# Коммит отменён, файлы вернулись в staging

git reset --mixed HEAD~1
# Коммит отменён, файлы вернулись в рабочую директорию

Отменить конкретный коммит в истории:

git revert abc123
# Создаст новый коммит, который отменяет abc123

Внести изменение в последний коммит:

echo "исправленный код" > src/app.js

git add src/app.js
git commit --amend
# Изменит последний коммит (ОСТОРОЖНО! Может сломать историю)

Объединить несколько коммитов:

# Интерактивный rebase последних 3 коммитов
git rebase -i HEAD~3

# В редакторе: замени 'pick' на 'squash' для объединения
# pick abc123 feat: часть 1
# squash def456 feat: часть 2
# squash ghi789 feat: часть 3

Использование коммитов в команде

Рабочий процесс:

# 1. Создаю ветку
git checkout -b feat/new-form

# 2. Делаю несколько коммитов
git commit -m "feat: создал компонент формы"
git commit -m "feat: добавил валидацию"
git commit -m "test: добавил тесты формы"

# 3. Отправляю в GitHub
git push origin feat/new-form

# 4. Создаю Pull Request для код-ревью
# В PR видна вся история коммитов

# 5. После одобрения - мерж в main
git merge feat/new-form

Коммиты и CI/CD

Автоматическое тестирование на коммит:

# При каждом push запускаются тесты
git push origin main
# GitHub Actions / GitLab CI запускают тесты
# Если тесты падают - коммит отклоняется

Semantic Versioning с коммитами:

# feat: создает MINOR версию (1.1.0)
git commit -m "feat: новая функция"

# fix: создает PATCH версию (1.0.1)
git commit -m "fix: исправил баг"

# BREAKING CHANGE: создает MAJOR версию (2.0.0)
git commit -m "feat!: переделал API"

Когда делать коммит

Правильный размер коммита:

# Плохо: огромный коммит с 50 файлами
git commit -m "wip: много всего"

# Хорошо: один логический изменение
git commit -m "feat: добавил кнопку входа"
git commit -m "feat: добавил валидацию email"
git commit -m "test: добавил тест для валидации"

# Правило: один коммит = одна логическая единица работы

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

1. Коммитьте часто - не жди конца дня
2. Понятные сообщения - используй Conventional Commits
3. Одна задача в коммите - не мешай разные изменения
4. Тесты проходят - коммит не должен ломать тесты
5. Работающий код - коммит должен быть рабочей версией
6. Релевантные файлы - не коммитьте мусор (.log, node_modules)
7. Код-ревью перед мержем - используй Pull Requests
8. История чистая - избегай хаоса в логе