Back to guides
GitHub: branches
Glossary overview
Back to guides

GitHub: branches

Популярные команды: https://github.com/joshnh/Git-Commands

Branching & Merging

CommandDescription
git branchList branches (the asterisk denotes the current branch)
git branch -aList all branches (local and remote)
git branch [branch name]Create a new branch
git branch -d [branch name]Delete a branch
git push origin --delete [branch name]Delete a remote branch
git checkout -b [branch name]Create a new branch and switch to it
git checkout -b [branch name] origin/[branch name]Clone a remote branch and switch to it
git branch -m [old branch name] [new branch name]Rename a local branch
git checkout [branch name]Switch to a branch
git checkout -Switch to the branch last checked out
git checkout -- [file-name.txt]Discard changes to a file
git merge [branch name]Merge a branch into the active branch
git merge [source branch] [target branch]Merge a branch into a target branch
git stashStash changes in a dirty working directory
git stash clearRemove all stashed entries
git stash popApply latest stash to working directory

Лучшая практика:

Разрешай конфликты в своей ветке, а не в main.

Если тебе нужно слить ветку feature/A в ветку main, не делай сразу git merge feature/A в main, особенно если main изменялся с момента создания ветки A.

Правильный порядок:
  1. Переключись в ветку feature/A:
git checkout feature/A

2. Подтяни изменения из main:

git pull origin main

3. Разреши конфликты в своей ветке (локально в A).

4. Протестируй, убедись, что всё работает.

5. Только потом сделай merge (или pull request) в main:

git checkout main
git pull origin main
git merge feature/A

Одна ветка — одна задача

Каждая ветка должна решать одну конкретную задачу: фича, багфикс, оптимизация и т.д.

Разберём живой сценарий.

Представь обычный рабочий день с WP или Laravel. У тебя сейчас есть стабильный main.
Клиент пишет: «нужно добавить webhook оплаты». Ты не лезешь в main. Создаёшь ветку от него:

git checkout main
git pull
git checkout -b feature/payment-webhook

Работаешь спокойно. Коммитишь.

Когда всё готово:

git push origin feature/payment-webhook
Теперь второй сценарий.

Ты делаешь фичу… и вдруг баг в проде. Классика жанра.

Не мешаешь фикс с фичей. Создаёшь новую ветку прямо от main:

git checkout main
git pull
git checkout -b fix/vat-rounding

Чинишь быстро:

git commit -m "fix: correct VAT rounding for EU prices"
git push origin fix/vat-rounding

Merge в main. Прод спасён. Фича продолжает жить отдельно.

Как обычно выглядит структура веток в реальном проекте:

main
 ├─ feature/payment-webhook
 ├─ feature/admin-filters
 ├─ fix/vat-rounding
 └─ refactor/user-service

Регулярно синхронизируйте с основной веткой

Перед merge или во время работы — подтягивайте изменения из main или dev, чтобы избежать конфликтов:

git checkout feature/my-feature
git pull origin main
git merge main

Используйте Pull Request (PR) для merge

Никогда не пушьте прямо в main, используйте PR:

  • Возможность ревью
  • Видимость истории
  • Интеграция с CI/CD
  • Проверка на конфликты

Удаляйте старые ветки

После merge:

git branch -d feature/old-branch        # локально
git push origin --delete feature/old-branch  # на GitHub

Чистота репозитория = легче ориентироваться.

Правильный способ переключаться

Есть 3 базовых инструмента:

  • Просто закоммитить перед переключением на другую ветку. Даже временный коммит лучше, чем потерянный код. Историю потом можно почистить rebase’ом.
  • git stash – кладем на полку. 
git stash
git checkout другая-ветка

// Вернуться
git stash pop

Это как положить код в карман, сходить в другую ветку, потом достать обратно.

  • Изменения не закоммичены, но не конфликтуют. Git может просто перенести их с тобой в другую ветку. Это выглядит как магия, но это нормально. Он видит, что файлы одинаковые в обеих ветках и разрешает переход. Но на это лучше не рассчитывать. Если изменения не закоммичены и мешают переключению, то вот тут Git скажет что-то вроде:
error: Your local changes would be overwritten by checkout

Он буквально защищает тебя от потери кода.

Не тяните ветку слишком долго

Долгоживущие ветки → частые конфликты. Рекомендуется:

  • Делать merge каждые 1–3 дня
  • Делать короткие PR

Video

Video: https://www.youtube.com/watch?v=QV0kVNvkMxc

МЫ создали 3 ветки:

В ветках feature-a и feature-b мы создали по одному новому файлу.

Теперь мы хотим смержить. Это вторая часть видео – https://www.youtube.com/watch?v=XX-Kct0PfFc

Переключаемся на ветку куда буедм мержить – master.

Мержим.

У нас появился js файл в основной ветке.

Мержим вторую ветку:

Пишет что использована “рукурсивная” стратегия, потому что на момент мержа, основная ветка уже имеет 1-й js файл, которого не было на момент создания 2-й ветки.

Теперь в оснвоной ветке 2 js файла:

Нет конфликтов, потому что пока мы разрабатывали в новой ветке, в ветке master ничего не менялось.

Сделаем конфликт.

Создаем новую ветку:

Переключаемся на основную ветку и меняем что-то в ней – добавили стиль.

Коммитим (в этом видео работаем на локалке, ничего не пушим на гит).

И переключаемся на новую ветку.

В новой ветке мы не знаем что добавили новый стиль.

Добавим тоже новый стиль:

Теперь нам надо смрежить новую ветку с оснвоной.

Сначала коммитим и переключаемся на основную ветку:

Мержим. Получаем конфликт.

Вручную исправили:

Теперь коммитим:

Получаем такой экран:

Пишем просто “:wq”.

Команда :wq используется в редакторе Vim, чтобы:

  • w — write (сохранить изменения в файле),
  • q — quit (выйти из редактора).

В контексте разрешения конфликта при мёрже (merge), когда Git открывает Vim для ввода commit message, пользователь редактирует сообщение и затем вводит :wq, чтобы:

  1. сохранить это сообщение;
  2. выйти из Vim;
  3. тем самым завершить процесс слияния — Git использует сохранённое сообщение и делает коммит.

Если вы просто закроете Vim без сохранения (:q), коммит не будет завершён. А если оставите сообщение пустым, Git может прервать коммит.

Смержилось:

Практика с неймингом feat / fix / refactor

Для фикса создал ветку.

➜  girlzz git:(main) git checkout -b fix/pagination
Switched to a new branch 'fix/pagination'

Сделал правки.

Коммитим в эту ветку. Но не пушим. Теперь можем спокойно переключаться на другую ветку, в нашем случае main.

Теперь надо взять последние изменения из ветки main и добавить их в твою рабочую ветку fix/pagination.

Зачем это вообще нужно?

Пока ты чинил пагинацию, в main могли появиться новые коммиты:

  • кто-то другой что-то поправил
  • ты сам с другого компа запушил
  • CI что-то обновил

И получается две параллельные реальности:

main:            A---B---C
fix/pagination:  A---B---D---E

Если ты сразу попробуешь влить свою ветку в main, то придется в ней решать конфликт.

Поэтому делают умнее: Сначала обновляют свою ветку последним состоянием main,
а уже потом мержат. Теперь так:

main:            A---B---C
fix/pagination:  A---B---C---D---E

Как это делается технически

2 варианта:

// merge main в свою ветку
git checkout fix/pagination
git fetch origin
git merge origin/main

// rebase своей ветки на свежий main
git checkout fix/pagination
git fetch origin
git rebase origin/main

Теперь наша ветка имеет и наши изминения и нет конфликтов с main.

Теперь можем запушить ветку на GitHub:

git push -u origin fix/pagination

Дальше можем слить в main (лучше через PR на GitHub: review, checks, merge).
Если без PR локально, то так:

git checkout main
git pull origin main
git merge fix/pagination
git push origin main

Дальше можем удалить ветку (по желанию, но это прям good tone):

git branch -d fix/pagination
git push origin --delete fix/pagination

Практика 2

Я хочу поработать с GSAP. Буду делать это в новой ветке.

У меня сейчас одна ветка:

Вот как через терминал посмотреть ветки:

PS D:\OSPanel\domains\syntaxsteps\wp-content\themes\syntaxsteps> git branch
* main

Сощдаем новую ветку “GSAP”.

Создали, но мы по прежнему находимся в ветке Main. Надо переключиться на новую ветку.

Или можно было одной командо создать новую ветку и сразу переключиться на нее:

git checkout -b GSAP

Теперь у нас 2 ветки:

Но в удаленном репо до сих пор одна ветка.

Если в удалённом репозитории (на GitHub) до сих пор отображается только одна ветка (например, main), а ты уже создал новую ветку (GSAP) локально, значит ты её ещё не запушил на GitHub.

Как отправить локальную ветку на удалённый репозиторий:

git push -u origin GSAP
  • push — отправляет ветку на GitHub.
  • -u — связывает локальную ветку с удалённой, чтобы в будущем можно было просто писать git push и git pull.
  • origin — имя удалённого репозитория (по умолчанию).
  • GSAP — имя ветки.

Проверить, какие ветки уже на GitHub:

git branch -r

Теперь на ГитХаб у нас появилась ветка:

related

Discover other Guides

View all guides View all guides

array_values()

Laravel: Exceptions

PHP: Exceptions

OOP: static::class vs self::class

OOP: Принципы

JS Promise / SetTimeOut