Best Practices для Git Коммитов 🎯

Делать коммиты — это искусство! Профессиональные разработчики следуют правилам, чтобы история проекта была чистой и понятной.

Основные правила

Золотое правило: 1 коммит = 1 изменение

❌ Плохо:

# Сделали всё за неделю → 1 коммит
git commit -m "работа за неделю"
# 50 файлов changed, 2000 insertions, 800 deletions 😱

✅ Хорошо:

git commit -m "feat: добавлен user model"
git commit -m "feat: создана форма логина"
git commit -m "fix: исправлена валидация email"
git commit -m "docs: обновлён README"
git commit -m "test: добавлены тесты для auth"
# = 5 понятных коммитов

Почему это важно:
- Легко понять что изменилось
- Можно откатить конкретное изменение
- Code review проходит быстрее
- История читается как книга

Правило 2: Пишите понятные commit messages

Формула: <тип>: <что сделано>

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

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

Примеры

✅ Отлично:

feat: добавлена поддержка двухфакторной аутентификации
fix: исправлена ошибка 500 при пустом email
docs: обновлена документация API endpoints
refactor: упрощена логика валидации форм
test: добавлены unit тесты для user service

❌ Плохо:

update
fix
done
asdfgh
коммит
work

Правило 3: Коммитьте работающий код

❌ Никогда:

git commit -m "wip"  # work in progress - код не работает!

Проблемы:
- Коллеги получат сломанный код
- CI/CD упадёт
- Нельзя откатиться на этот коммит

✅ Всегда:

# Перед коммитом:
1. Запустите код — работает?
2. Пройдите тесты — зелёные?
3. Проверьте линтер — нет ошибок?
4. Только потом commit!

Если нужно сохранить недоделанное:

git stash  # спрятать временно
# Работаете над другим
git stash pop  # вернули обратно

Правило 4: Проверяйте diff перед коммитом

Всегда смотрите ЧТО коммитите!

В GitHub Desktop:
1. Вкладка Changes
2. Кликаете на файл
3. Смотрите diff (зелёное/красное)
4. Убедитесь что всё правильно

Частые ошибки:
- ❌ Закоммитили console.log() для дебага
- ❌ Закоммитили .env с паролями
- ❌ Закоммитили TODO комментарии
- ❌ Случайно удалили важный код

Правило 5: Используйте .gitignore

Что НЕ коммитить:

# .gitignore
node_modules/
__pycache__/
.env
*.log
.DS_Store
dist/
build/

Создайте .gitignore СРАЗУ:

# В начале проекта:
1. Создайте .gitignore
2. Г Добавьте паттерны
3. Закоммитьте
4. Профит — мусор не попадёт в Git!

Продвинутые правила

Правило 6: Делайте commit message на русском или английском (но одинаково)

❌ Плохо (микс языков):

git commit -m "fix bug в функции login"
git commit -m "добавлен new feature для users"

✅ Хорошо (один язык):

# Русский:
git commit -m "fix: исправлен баг в функции login"
git commit -m "feat: добавлена новая функция для юзеров"

# Английский:
git commit -m "fix: fixed bug in login function"
git commit -m "feat: added new feature for users"

Совет: В open source проектах — английский. В своих — как удобно.

Правило 7: Добавляйте контекст в Description

Summary — краткое что, Description — подробное как и зачем

✅ Пример:

Summary:

fix: исправлена ошибка при загрузке аватара

Description:

Проблема:
- При загрузке PNG > 5MB возникала ошибка 500
- Не было валидации размера файла

Решение:
- Добавлена проверка размера (макс. 5MB)
- Возвращается 400 с понятной ошибкой
- Обновлены тесты

Fixes #123

Полезно когда:
- Изменение неочевидное
- Нужно объяснить “почему”
- Ссылка на issue/task
- Code review

Правило 8: Коммитьте часто, push реже

Workflow:

# Работаете локально:
git commit -m "feat: добавлен model"
git commit -m "feat: добавлен form"
git commit -m "feat: добавлен view"
git commit -m "test: тесты для view"

# Всё работает? Push все разом:
git push

Почему:
- Локал ьно — экспериментируете свободно
- Push — когда всё готово и работает
- Можно squash коммиты перед push
- Не мешаете команде недоделанным кодом

Правило 9: Не коммитьте секреты!

❌ ОПАСНО:

# settings.py
SECRET_KEY = "django-secret-123456"
DATABASE_PASSWORD = "password123"
API_KEY = "sk_live_1234567890"

✅ Правильно:

# settings.py
import os
SECRET_KEY = os.getenv('SECRET_KEY')
DATABASE_PASSWORD = os.getenv('DB_PASSWORD')
API_KEY = os.getenv('API_KEY')

# .gitignore
.env

# .env (НЕ коммитится!)
SECRET_KEY=django-secret-123456
DB_PASSWORD=password123
API_KEY=sk_live_1234567890

Если уже закоммитили:
1. Смените пароли НЕМЕДЛЕННО!
2. Удалите из истории (git filter-branch)
3. Force push (опасно!)

Правило 10: Следуйте Conventional Commits

Стандарт индустрии:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Примеры:

feat(auth): add two-factor authentication
fix(api): handle null values in user endpoint
docs(readme): update installation instructions
refactor(payment): simplify checkout logic
test(auth): add unit tests for login
chore(deps): update dependencies to latest

Scope (опционально) — где изменение:
- auth — авторизация
- api — API endpoints
- ui — интерфейс
- db — база данных

Checklist перед каждым коммитом

• [ ] Код работает (запустили и проверили)
• [ ] Тесты проходят (если есть)
• [ ] Посмотрели diff — всё правильно
• [ ] Commit message понятное
• [ ] Нет секретов в коде
• [ ] Нет закомментированного кода
• [ ] Нет console.log / print для дебага
• [ ] .gitignore настроен

Примеры хороших коммит-историй

Проект todo-app:

feat: initial project setup
feat: add task model and database schema
feat: create API endpoint for task creation
fix: validate task title is not empty
test: add tests for task creation
docs: add API documentation
refactor: extract validation logic to separate function
feat: add task completion functionality
fix: prevent duplicate task creation
docs: update README with usage examples

Видно эволюцию проекта! 📈

Антипаттерны (чего избегать)

❌ Коммиты “update”:

git commit -m "update"
git commit -m "update 2"
git commit -m "final update"
git commit -m "final update forreals"
git commit -m "ok this is final"

❌ Коммиты всего про екта:

git add .
git commit -m "project"  # 500 файлов!

❌ Fixing typo в 10 коммитах:

git commit -m "fix typo"
git commit -m "fix another typo"
git commit -m "fix typo in fix typo"
...

Как исправить плохую практику?

Если уже накоммитили плохо:

1. Локально (не запушили) — можно исправить:
   bash git commit --amend -m "Новое сообщение"

2. Squash коммитов:
   bash git rebase -i HEAD~3 # объединить последние 3

3. Запушили — сложнее:
   - Оставьте как есть (урок на будущее)
   - Или force push (опасно для команды!)

Лучше: Делайте правильно с самого начала!

Заключение

Хорошие коммиты = чистая история = счастливая команда!

Главное:
1. 1 коммит = 1 изменение
2. Понятные сообщения
3. Работающий код
4. Проверяйте diff
5. Испо льзуйте .gitignore

Следуйте этим правилам — и ваш GitHub профиль будет выглядеть профессионально! 🎯