Обновить основную веткуMoved
Перед созданием ветки убедись, что у тебя свежий код.
1git switch main
2git pull origin main
В старых статьях встретится git checkout main — это то же самое. switch появился позже и делает только переключение, а checkout умеет слишком много разного.
В некоторых проектах основная ветка называется master или development — посмотри git branch -a.
git switch main && git pull origin mainСоздать веткуMoved
Флаг -c создаёт ветку и сразу переключает на неё.
1git switch -c feature/new-feature
Старый вариант той же команды: git checkout -b feature/new-feature.
Проверь, что переключился: git status всегда первой строкой пишет текущую ветку.
git switch -c feature/new-featureСделать коммитыMoved
1git add .
2git commit -m "feat: добавлена новая функция"
git add . добавляет всё сразу — удобно, но опасно: легко захватить лишнее. Сначала смотри git status, потом добавляй.
Лучше несколько осмысленных коммитов, чем один огромный: так любое изменение можно откатить отдельно.
git statusПериодически подтягивать основную веткуRecommendedMoved
Если работа идёт не один день, основная ветка уходит вперёд.
1git switch main
2git pull origin main
3git switch feature/new-feature
4git merge main
Если возникнут конфликты, git о них скажет и остановится.
git merge mainОтправить ветку на серверMoved
1git push -u origin feature/new-feature
Флаг -u связывает локальную ветку с удалённой — дальше достаточно просто git push.
git push -u origin feature/new-featureОткрыть pull requestMoved
На GitHub, GitLab или Bitbucket создай PR из своей ветки в основную.
В описании напиши, что сделано и зачем. Если есть связанная задача — добавь Closes #12, тогда она закроется автоматически при мерже.
Удалить ветку после мержаMoved
После того как PR смержен:
1git branch -d feature/new-feature
2git push origin --delete feature/new-feature
3git remote prune origin
Важно про -d и -D: маленькая -d откажется удалять ветку, если её коммиты никуда не слиты. Большая -D удалит в любом случае. Пользуйся -d — это встроенная защита от потери работы.
git branch -d feature/new-featureВернуться на основную ветку и обновитьсяMoved
1git switch main
2git pull
Забыть этот шаг — классика: следующая ветка будет создана от устаревшего состояния, и круг замкнётся.
git switch main && git pullПроверить актуальную версию GitAdded
Убедись, что у тебя установлена последняя версия Git, чтобы избежать проблем с устаревшими командами и флагами.
git --version# Работа с веткамиRemoved
# Работа с ветками
Ветка позволяет работать над изменением, не трогая то, что уже работает. Это главное, что даёт git: эксперимент становится бесплатным.
Порядок такой: обновиться → создать ветку → коммиты → синхронизация → push → pull request → мерж → удаление ветки.
**Главное правило:** ветку создавай **до** того, как начал менять файлы, а не после. Иначе легко обнаружить себя с коммитами не в той ветке.
## Как называть веткиRemoved
## Как называть ветки
Имя ветки читают другие люди — оно должно сразу говорить, что внутри.
| Префикс | Для чего | Примеры |
|---|---|---|
| `feature/` | Новая функциональность | `feature/user-authentication`, `feature/payment-integration` |
| `fix/` | Исправление ошибки | `fix/login-bug`, `fix/typo-in-readme` |
| `enhancement/` | Улучшение существующего | `enhancement/performance-optimization` |
| `test/` | Тесты | `test/add-unit-tests`, `test/integration-tests` |
| `docs/` | Документация | `docs/improve-readme`, `docs/api-documentation` |
**Правила:**
- **Префикс обязателен** — по нему виден тип изменения без чтения кода.
- **Описывай, а не нумеруй.** `feature/new-style` понятно, `feature/task-42` — нет.
- **Слова через дефис:** `feature/new-style`, а не `feature/newstyle`.
- **Без пробелов** — имя с пробелом придётся каждый раз экранировать в терминале.
## Разбор случая: слияние упало в конфликтыRemoved
## Разбор случая: слияние упало в конфликты
Ниже — реальный случай, а не учебный пример. Задача была: слить фича-ветку в `development`, а потом `development` в `main`.
Первая часть прошла чисто. На второй git выдал:
```
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
CONFLICT (content): Merge conflict in src/app/App.tsx
CONFLICT (content): Merge conflict in src/widgets/footer/ui/Footer.tsx
...
Automatic merge failed; fix conflicts and then commit the result.
```
**Что было сделано:**
```bash
git merge --abort
```
Слияние отменили целиком и вернулись к исходному состоянию. `main` остался нетронутым.
**Почему это правильное решение.** Когда конфликтов семь штук в незнакомых файлах, разбирать их наскоро в терминале — верный способ сломать стабильную ветку. `merge --abort` — это кнопка «отмена», и о ней надо знать заранее.
**Но вот что важнее.** Задача так и осталась невыполненной: в `main` ничего не уехало. Конфликты не исчезли — их просто отложили. Разобрать их всᑑ равно придётся, и лучше через pull request: там видно каждый конфликт отдельно, есть история обсуждения и можно откатиться без последствий.
**Вывод:** локальный `git merge` в `main` — плохая идея в принципе. Он обходит ревью и проверки. Слияние в основную ветку должно идти через PR.
## Шпаргалка по командамRemoved
## Шпаргалка по командам
```bash
# где я и что происходит
git status
git branch -a
# начать работу
git switch main && git pull
git switch -c feature/my-feature
# сохранить
git add .
git commit -m "feat: описание"
git push -u origin feature/my-feature
# подтянуть чужие изменения
git switch main && git pull
git switch feature/my-feature && git merge main
# если слияние пошло не так
git merge --abort
# убрать за собой
git branch -d feature/my-feature
git push origin --delete feature/my-feature
git remote prune origin
```
Подробно и на русском — книга [Pro Git](https://git-scm.com/book/ru/v2), она бесплатная.