Уровень: «базу знаешь, практики мало». Это не учебник Git с нуля, а как мы ведём ветки и PR, зачем так делают в компаниях и где обычно ломаются новички.
Операционные правила (коротко) — в working-agreement.md. Здесь — теория и карта действий.
История git — лента коммитов. Ветка — указатель на коммит + свобода наращивать историю, не ломая чужую линию.
Без веток все коммитят в одну линию → невозможно:
PR (Pull Request) — предложение: «влить мою линию коммитов в целевую ветку» + обсуждение + CI + запись решения. В компаниях код почти никогда не пушат напрямую в main/dev без PR (исключения — крошечные hotfix по договорённости; у нас тоже лучше через PR).
main ← прод (default на сайте GitHub); стабильно, редко
↑ PR
dev ← рабочая сборка: сюда мержим завершённые задачи
↑ PR
app-12-web ← продуктовая задача (issue #12, label web)
pr-16-gitflow ← практика (issue #16)
↑ опционально
app-12-web-btn ← подзадача, если объём реально разъехался
| Ветка | Роль | Кто мержит куда |
|---|---|---|
main |
Прод; остаётся default branch на GitHub | Только из dev, когда сознательно решили выкатить |
dev |
Интеграция | Сюда — все завершённые app-* / pr-* |
app-<n>-<label> |
Задача продукта | PR → dev |
pr-<n>-<label> |
Учебная практика | PR → dev |
Формат строго: {app\|pr}-{номер}-{label} (kebab), примеры: app-13-docs, pr-12-gitverse.
Создание ветки: Cursor /gh-start-task N или scripts/gh/start-task.sh N.
Почему не Git Flow Atlassian «как в учебнике»? Классический Git Flow (develop + release + hotfix) тяжеловат для одного человека. Наш вариант ближе к GitHub Flow + отдельный dev: просто, но уже тренирует merge и конфликты как на работе.
git checkout dev
git pull origin dev
git checkout -b app-12-web # или: scripts/gh/start-task.sh 12
feat: … новая возможность
fix: … баг
docs: … только документация / plan
chore: … рутина (игноры, мелкий конфиг)
ci: … пайплайн
refactor: … без смены поведения
git push -u origin HEAD
dev (не в main). В описании:Closes #12
или Refs #12, если issue ещё не полностью закрываем.
git checkout dev
git pull origin dev
Ветку задачи после merge можно удалить на remote (кнопка в UI PR) и локально: git branch -d app-12fr.
Нормальная картина:
dev → app-12fr (оптимизация загрузки)
→ app-12fr-btn (починить подгрузчик кнопки)
Имеет смысл, если:
dev;Иначе проще чеклист в одном PR — меньше админки.
Слияние: сначала PR подзадачи → в app-12fr, потом PR app-12fr → в dev. На каждом шаге возможны конфликты — это учебный навык, не наказание.
Две ветки меняли одни и те же строки (или соседние так, что git не уверен). При merge/rebase git останавливается и просит человека выбрать итог.
Типичные причины у нас:
git pull на dev перед веткой;dev чужой PR затронул твой файл, а ты ещё не подтянул dev в свою ветку.Подтянуть свежий dev в свою ветку до финального PR (привычка компаний):
git checkout app-12-web
git fetch origin
git merge origin/dev
# или: git rebase origin/dev — см. §6
Разбор конфликта:
<<<<<<<, =======, >>>>>>>.git add … → git commit (если был merge) или git rebase --continue.Пока мало практики — merge предпочтительнее rebase: история чуть шумнее, но проще откатить и понять. Rebase учим отдельно, когда merge уже не пугает.
Плохие идеи на старте:
git push --force в dev / main;| Стратегия | Что получается в dev |
Когда уместно |
|---|---|---|
| Merge commit | Видна ветка + merge-узел | Учёба, прозрачная история «эта задача влилась вот тут» |
| Squash | Все коммиты задачи → один | Много мелких «WIP» коммитов, хочется чистый dev |
| Rebase + merge | Линейная история | Когда уже уверенно владеешь rebase |
Для DPline на Фазе 0: Merge commit или Squash — оба ок. Главное — единообразие на ближайшие недели; зафиксируем привычку в ADR, если станет больно.
main vs dev — дисциплина выкладкиdev можно сломать мелочь на день — это интеграционная ветка.main — только то, что сам готов считать стабильным срезом.Перенос dev → main: отдельный PR, когда есть смысл (например, после вертикального среза Фазы 0). Не каждый день.
Hotfix «только в main» пока не закладываем — чиним в ветке от dev, потом уже решаем, нужен ли срочный PR в main.
| Событие | Project | Git |
|---|---|---|
| Взял задачу | Ready → In Progress | создал ветку от dev |
| Открыл PR | → Review | PR в dev |
| Merge | → Done | Closes #N закроет issue |
| Сессия кончилась | поля Actual / заметка | push обязателен |
Issue без ветки = ещё не работа. Ветка без issue = работа без учёта (для нас плохо: Cursor и ты теряете нить).
Имя ветки строго type-номер-label (app-12-web). Label берётся из meta в теле issue (создаёт /gh-create-task).
| Ошибка | Почему плохо | Что вместо |
|---|---|---|
Коммитить сразу в dev |
Нет ревью, сложно откатить одну задачу | Всегда ветка + PR |
Ветка от устаревшего dev |
Поздние огромные конфликты | pull перед checkout -b |
| Одна ветка на 5 issues | Непонятно, что мержить | 1 issue ≈ 1 ветка |
| «Я потом залью» без push | Потеря при сбое диска / смена машины | Push до закрытия сессии |
| Force-push в общую ветку | Ломает историю другим (и себе) | Force только в свою feature-ветку, осознанно |
| Игнор CI на PR | Зелёный CI — часть Definition of Done | Чинить до merge (когда CI появится, #14) |
devapp-… / pr-… с номером issuedev, в теле Closes #N или Refs #Ngit checkout dev && git pullБлижайшие тренировки не «выучить команды», а пройти путь глазами:
#16).dev уже ушёл вперёд → merge origin/dev в свою → конфликт на md → разрешить.git log --oneline --graph.Когда упрёшься в конкретный экран GitHub или сообщение git — разберём этот случай, а не абстрактный учебник.