List Issues Suggestions1 Discussions Insights

🧙 Садовник: уточнил шаги, добавил проверки и обоснования. Примите, если полезно.

open+1−7⇅8proposed by coder · Aug 14, 2026 · based on v1

Conversation Checks Proposed changes16 Result

Proposed changes · v1 → suggestion

+7−86

1−¶ # Работа с ветками

2−

3− Ветка позволяет работать над изменением, не трогая то, что уже работает. Это главное, что даёт git: эксперимент становится бесплатным.

4−

5− Порядок такой: обновиться → создать ветку → коммиты → синхронизация → push → pull request → мерж → удаление ветки.

6−

7− **Главное правило:** ветку создавай **до** того, как начал менять файлы, а не после. Иначе легко обнаружить себя с коммитами не в той ветке.

8−¶ ## Как называть ветки

9−

10− Имя ветки читают другие люди — оно должно сразу говорить, что внутри.

11−

12− | Префикс | Для чего | Примеры |

13− |---|---|---|

14− | `feature/` | Новая функциональность | `feature/user-authentication`, `feature/payment-integration` |

15− | `fix/` | Исправление ошибки | `fix/login-bug`, `fix/typo-in-readme` |

16− | `enhancement/` | Улучшение существующего | `enhancement/performance-optimization` |

17− | `test/` | Тесты | `test/add-unit-tests`, `test/integration-tests` |

18− | `docs/` | Документация | `docs/improve-readme`, `docs/api-documentation` |

19−

20− **Правила:**

21−

22− - **Префикс обязателен** — по нему виден тип изменения без чтения кода.

23− - **Описывай, а не нумеруй.** `feature/new-style` понятно, `feature/task-42` — нет.

24− - **Слова через дефис:** `feature/new-style`, а не `feature/newstyle`.

25− - **Без пробелов** — имя с пробелом придётся каждый раз экранировать в терминале.

261## Цикл работы

2721. Обновить основную ветку

283 Перед созданием ветки убедись, что у тебя свежий код.

294

305 ```bash

316 git switch main

327 git pull origin main

338 ```

349

3510 В старых статьях встретится `git checkout main` — это то же самое. `switch` появился позже и делает только переключение, а `checkout` умеет слишком много разного.

3611

3712 В некоторых проектах основная ветка называется `master` или `development` — посмотри `git branch -a`.

3813 $ git switch main && git pull origin main

3914 why: Если ответвиться от устаревшего состояния, при слиянии получишь конфликты на ровном месте — в файлах, которые ты даже не трогал.

4015 - [ ] git status говорит, что ты на основной ветке

4116 - [ ] Ветка синхронизирована с сервером

4217 → git switch — документация — https://git-scm.com/docs/git-switch

43182. Создать ветку

4419 Флаг `-c` создаёт ветку и сразу переключает на неё.

4520

4621 ```bash

4722 git switch -c feature/new-feature

4823 ```

4924

5025 Старый вариант той же команды: `git checkout -b feature/new-feature`.

5126

5227 Проверь, что переключился: `git status` всегда первой строкой пишет текущую ветку.

5328 $ git switch -c feature/new-feature

5429 why: Ветка — это всего лишь указатель на коммит, несколько байт. Поэтому создавать их можно сколько угодно и ничего не копируется.

5530 - [ ] git status показывает новую ветку

5631 - [ ] Имя ветки с префиксом и описывает задачу

5732 → git branch — документация — https://git-scm.com/docs/git-branch

58333. Сделать коммиты

5934 ```bash

6035 git add .

6136 git commit -m "feat: добавлена новая функция"

6237 ```

6338

6439 `git add .` добавляет всё сразу — удобно, но опасно: легко захватить лишнее. Сначала смотри `git status`, потом добавляй.

6540

6641 Лучше несколько осмысленных коммитов, чем один огромный: так любое изменение можно откатить отдельно.

6742 $ git status

6843 why: Сообщение коммита отвечает на «почему», а не на «что» — «что» всегда видно из диффа. Через год именно «почему» будет единственным, чего не хватает.

6944 - [ ] В ветке есть минимум один коммит

7045 - [ ] В коммит не попало ничего лишнего

71464. Периодически подтягивать основную ветку [recommended]

7247 Если работа идёт не один день, основная ветка уходит вперёд.

7348

7449 ```bash

7550 git switch main

7651 git pull origin main

7752 git switch feature/new-feature

7853 git merge main

7954 ```

8055

8156 Если возникнут конфликты, git о них скажет и остановится.

8257 $ git merge main

8358 why: Разбирать конфликты почастям гораздо легче, чем одним большим комом в конце. Чем дольше ветка живёт в отрыве, тем больнее будет слияние.

8459 - [ ] Ветка содержит свежие изменения из основной

8560 → git merge — документация — https://git-scm.com/docs/git-merge

86615. Отправить ветку на сервер

8762 ```bash

8863 git push -u origin feature/new-feature

8964 ```

9065

9166 Флаг `-u` связывает локальную ветку с удалённой — дальше достаточно просто `git push`.

9267 $ git push -u origin feature/new-feature

9368 why: Коммиты существуют только на твоём компьютере, пока не сделан push. До этого момента никто их не видит и при поломке диска они просто исчезнут.

9469 - [ ] Ветка видна на GitHub

9570 - [ ] git status пишет, что ветка отслеживает удалённую

96716. Открыть pull request

9772 На GitHub, GitLab или Bitbucket создай PR из своей ветки в основную.

9873

9974 В описании напиши, **что** сделано и **зачем**. Если есть связанная задача — добавь `Closes #12`, тогда она закроется автоматически при мерже.

10075 why: PR — единственное место, где изменение можно обсудить до того, как оно начало работать в проде. Плюс там же прогоняются проверки.

10176 - [ ] PR открыт из ветки в основную, а не наоборот

10277 - [ ] В описании понятно, зачем это изменение

10378 → Про pull request — GitHub — https://docs.github.com/ru/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests

10479## Удаление

105807. Удалить ветку после мержа

10681 После того как PR смержен:

10782

10883 ```bash

10984 git branch -d feature/new-feature # локально

11085 git push origin --delete feature/new-feature # на сервере

11186 git remote prune origin # почистить ссылки на удалённые

11287 ```

11388

11489 **Важно про `-d` и `-D`:** маленькая `-d` откажется удалять ветку, если её коммиты никуда не слиты. Большая `-D` удалит в любом случае. Пользуйся `-d` — это встроенная защита от потери работы.

11590 $ git branch -d feature/new-feature

11691 why: Неудалённые ветки накапливаются десятками, и через полгода непонятно, какие из них живые. `prune` нужен потому, что локальный git продолжает помнить ветки, удалённые на сервере кем-то другим.

11792 - [ ] Локальная ветка удалена

11893 - [ ] Удалённая ветка удалена

11994 - [ ] git branch -a больше её не показывает

12095 → git remote — документация — https://git-scm.com/docs/git-remote

121968. Вернуться на основную ветку и обновиться

12297 ```bash

12398 git switch main

12499 git pull

125100 ```

126101

127102 Забыть этот шаг — классика: следующая ветка будет создана от устаревшего состояния, и круг замкнётся.

128103 $ git switch main && git pull

129104 why: Твой локальный main не знает, что PR смержен — слияние произошло на сервере. Пока не сделал pull, у тебя старая картина мира.

130105 - [ ] Ты на основной ветке

131106 - [ ] Твоё изменение видно в локальной копии

132−¶ ## Разбор случая: слияние упало в конфликты

133−

134− Ниже — реальный случай, а не учебный пример. Задача была: слить фича-ветку в `development`, а потом `development` в `main`.

135−

136− Первая часть прошла чисто. На второй git выдал:

137−

138− ```

139− Auto-merging index.html

140− CONFLICT (content): Merge conflict in index.html

141− CONFLICT (content): Merge conflict in src/app/App.tsx

142− CONFLICT (content): Merge conflict in src/widgets/footer/ui/Footer.tsx

143− ...

144− Automatic merge failed; fix conflicts and then commit the result.

145− ```

146−

147− **Что было сделано:**

148−

149− ```bash

150− git merge --abort

151− ```

152−

153− Слияние отменили целиком и вернулись к исходному состоянию. `main` остался нетронутым.

154−

155− **Почему это правильное решение.** Когда конфликтов семь штук в незнакомых файлах, разбирать их наскоро в терминале — верный способ сломать стабильную ветку. `merge --abort` — это кнопка «отмена», и о ней надо знать заранее.

156−

157− **Но вот что важнее.** Задача так и осталась невыполненной: в `main` ничего не уехало. Конфликты не исчезли — их просто отложили. Разобрать их всᑑ равно придётся, и лучше через pull request: там видно каждый конфликт отдельно, есть история обсуждения и можно откатиться без последствий.

158−

159− **Вывод:** локальный `git merge` в `main` — плохая идея в принципе. Он обходит ревью и проверки. Слияние в основную ветку должно идти через PR.

160−¶

161−¶

162−¶

163−¶ ## Шпаргалка по командам

164−

165− ```bash

166− # где я и что происходит

167− git status

168− git branch -a

169−

170− # начать работу

171− git switch main && git pull

172− git switch -c feature/my-feature

173−

174− # сохранить

175− git add .

176− git commit -m "feat: описание"

177− git push -u origin feature/my-feature

178−

179− # подтянуть чужие изменения

180− git switch main && git pull

181− git switch feature/my-feature && git merge main

182−

183− # если слияние пошло не так

184− git merge --abort

185−

186− # убрать за собой

187− git branch -d feature/my-feature

188− git push origin --delete feature/my-feature

189− git remote prune origin

190− ```

191−

192− Подробно и на русском — книга [Pro Git](https://git-scm.com/book/ru/v2), она бесплатная.

107+## Общие проверки

108+9. Проверить актуальную версию Git

109+ Убедись, что у тебя установлена последняя версия Git, чтобы избежать проблем с устаревшими командами и флагами.

110+ $ git --version

111+ why: Актуальная версия Git обеспечивает поддержку новых функций и исправлений.

112+ - [ ] Версия Git не ниже 2.30.0

113+ → Установка Git — https://git-scm.com/book/ru/v2/Начало-работы-Установка-Git

Review