12. Best Practices

Git: Лучшие Практики (Best Practices)

Эффективное использование Git выходит за рамки запоминания команд. Оно включает в себя следование набору лучших практик, которые делают историю вашего проекта чистой, понятной и легкой для поддержки. Эти принципы помогают командам работать слаженно и минимизируют ошибки.

Задача: Построить чистую, понятную и эффективную историю проекта Git.

Мы рассмотрим ключевые практики и команды для их реализации.

---

1. Атомарные Коммиты: Одно изменение за раз

Задача: Каждый коммит должен представлять собой одно, логически связанное и самодостаточное изменение. Это упрощает откат изменений, ревью кода и понимание истории.

Команды:

git add .
# Добавить изменения интерактивно (позволяет выбрать части файлов)
git add -p
# Закоммитить изменения
git commit -m "feat: Добавить модуль авторизации пользователя"

Пример: Вместо одного большого коммита “Реализовать фичу X”, разбейте его:

1. feat: Добавить базовую структуру для модуля X
2. feat: Реализовать функцию А в модуле X
3. fix: Исправить баг в функции А
4. refactor: Оптимизировать функцию Б в модуле X

Визуальная схема:

Неправильно:
A --- B (Огромный коммит)

Правильно:
A --- B' --- C' --- D' (Атомарные коммиты)

Последствия: Легче найти источник бага, проще провести git revert или git cherry-pick.

---

2. Осмысленные Сообщения Коммитов

Задача: Сообщение коммита должно быстро дать понять, что было сделано и почему. Это критично для навигации по истории и code review.

Правила:

• Тема (первая строка): Краткое описание изменения (императивный залог, до 50 символов).
• Пустая строка: Разделяет тему и тело.
• Тело (дополнительные детали): Подробности, обоснование, ссылки на задачи (до 72 символов на строку).

Команда:

# Короткое сообщение
git commit -m "feat: Добавить страницу настроек профиля"

# Подробное сообщение через редактор
git commit

Пример:

feat: Add user authentication module

This commit introduces a new user authentication module with
email/password login. It includes models, views, and controllers.
Closes #123.

Последствия: Ускоряет процесс code review, позволяет быстро понять контекст изменения, улучшает ведение журнала изменений.

---

3. Чистая История: Rebase или Merge --no-ff

Задача: Поддерживать линейную и легко читаемую историю проекта без лишних “веток слияния”.

Команды:

# Обновить ветку, применяя изменения из master поверх локальных
git pull --rebase
# Интерактивный rebase (позволяет squish, reword, drop коммиты)
git rebase -i HEAD~3
# Слияние с сохранением истории ветки, но без создания быстрого проматывания
git merge --no-ff <branch-name>

Пример Rebase: Представьте master и feature ветки:

A -- B -- C (master)
     \
      D -- E (feature)

# Перемещаем коммиты D и E поверх C
git checkout feature
git rebase master

Результат:

A -- B -- C -- D' -- E' (feature)

Важно: Никогда не делайте rebase на публичной ветке, которую уже кто-то pulled!

Пример Merge --no-ff:

A -- B -- C (master)
     \
      D -- E (feature)

# Сливаем feature в master, создавая коммит слияния
git checkout master
git merge --no-ff feature

Результат:

A -- B -- C --- F (master, merge commit)
     \         /
      D ----- E (feature)

Последствия: Rebase создает линейную историю (может перезаписывать историю), merge --no-ff сохраняет граф, но без “быстрого проматывания” (fast-forward), что сохраняет информацию о слиянии ветки.

---

4. Ветки для Фич/Багфиксов

Задача: Изолировать работу над каждой новой функцией или исправлением ошибки в отдельной ветке.

Команды:

# Создать новую ветку и сразу переключиться на нее
git checkout -b feature/add-analytics
# Просмотреть все ветки
git branch -a
# Отправить ветку на удаленный репозиторий
git push -u origin feature/add-analytics

Визуальная схема:

master: A -- B -- F
               \    /
feature:        C -- D -- E

Последствия: Позволяет работать параллельно, безопасно экспериментировать и легко проводить code review через Pull Request.

---

5. Проверка Перед Пушем (Pre-Push Review)

Задача: Убедиться, что вы отправляете только готовые и проверенные изменения.

Команды:

# Посмотреть состояние рабочей директории
git status
# Посмотреть изменения, подготовленные к коммиту
git diff --cached
# Просмотреть историю коммитов (кратко и с графом)
git log --oneline --graph --all

Последствия: Предотвращает попадание незавершенных изменений или ошибок в основной репозиторий, экономит время коллег.

---

Типичные Проблемы и Как Их Избежать

• Публичный Rebase: Никогда не делайте git rebase на ветках, которые уже были отправлены (pushed) и использованы другими разработчиками. Это переписывает историю и может вызвать конфликты.
• Огромные Коммиты: Избегайте коммитов, которые меняют десятки файлов и сотни строк. Используйте git add -p для создания атомарных коммитов.
• Неинформативные Сообщения: “Fix bug”, “Update”, “Changes” — бесполезны. Всегда пишите, ЧТО было сделано и ПОЧЕМУ.

---

Практика

1. Создайте новую ветку: git checkout -b my-new-feature.
2. Внесите первое небольшое изменение (например, добавьте новую строку в файл).
3. Закоммитьте его с атомарным, осмысленным сообщением: git commit -m "feat: Добавить приветственное сообщение в index.html".
4. Внесите второе, отличающееся изменение (например, переименуйте переменную).
5. Закоммитьте его: git commit -m "refactor: Переименовать переменную 'temp' в 'data' для ясности".
6. Сделайте git log --oneline --graph и убедитесь, что история чистая.
7. Переключитесь на master: git checkout master.
8. Слейте вашу ветку, используя git merge --no-ff my-new-feature или сделайте git pull --rebase origin master (если есть удаленные изменения) и затем git rebase master из вашей ветки, прежде чем ее слить (после ребейза нужно будет сделать git merge my-new-feature из master).
9. Удалите локальную ветку: git branch -d my-new-feature.

🔗 Connected Topics

• Init & Commit
• Branches
• Merge & Rebase
• Remote & Push/Pull
• Conflicts
• GitHub Workflow
• Cherry-pick & Stash

Интерактивный пример

Хорошие vs плохие commit messages: