В одиночку достаточно коммитов и push; в команде нужны правила веток, код-ревью и стратегия разрешения конфликтов. Иначе история превращается в хаос, а слияния — в потерю времени.
Модель веток
Git Flow, GitHub Flow или упрощённый вариант: main/master — стабильная линия; разработка — в feature-ветках; релиз — через merge или тег. Важно зафиксировать в регламенте: какие ветки долгоживущие, как именовать, когда удалять.
Код-ревью
Pull request или merge request: описание изменения, ссылка на задачу, самодостаточный дифф. Ревьюер проверяет логику, стиль, тесты и документацию. Автоматические проверки (линтеры, тесты) снижают нагрузку на ревьюера.
Конфликты
Чаще — при слиянии долгоживущих веток или при повторном слиянии main в feature. Решение: обновлять feature от main регулярно; конфликтующие участки разрешать вручную, сохраняя смысл обеих сторон. После разрешения — проверить сборку и тесты.
Типичные команды и сценарии
| Сценарий | Команда / действие |
|---|---|
| Создать ветку от main | git checkout main && git pull && git checkout -b feature/name |
| Подтянуть main в feature | git fetch origin main && git merge origin/main или git rebase origin/main |
| Разрешить конфликт | Открыть файл, убрать маркеры <<</===/>>>, сохранить смысл, git add, git commit |
| Отменить последний коммит (локально) | git reset --soft HEAD~1 (сохранить изменения) или --hard (отменить) |
| Посмотреть историю | git log --oneline -n 20, git log -p file |
Правила работы с Git стоит описать в базе знаний команды: тогда и новички, и RAG-чат смогут давать ответы по вашим регламентам.
Практики применения
- Зафиксируйте модель веток и именование; PR/MR с описанием и авто-проверками.
- Опишите регламенты в базе знаний — новички и чат по архиву дадут согласованные ответы.
Кратко: зафиксируйте модель веток (main, feature, именование). PR/MR с описанием и авто-проверками. Конфликты — регулярно подтягивать main в feature; после разрешения — сборка и тесты.