Как создать новую ветку в GitHub
Быстрые ссылки
- Что такое ветка?
- Создание ветки через сайт GitHub
- Создание ветки через командную строку
Работать напрямую в ветке main репозитория GitHub рискованно: есть шанс запушить баги в рабочую версию продукта. Чтобы этого избежать, создавайте отдельную ветку и проводите в ней все изменения. Ниже — подробное руководство.
Что такое ветка?
Ветка — это копия проекта Git, которую вы можете менять независимо от основной версии и затем объединить с основным кодом.
Когда вы создаёте репозиторий в GitHub, по умолчанию появляется одна ветка — “main” (ранее “master”). Это основная ветка, где обычно хранится рабочий (production) код. Если вы пушите изменения прямо в main, вы вносите изменения напрямую в рабочий продукт.
Проблема в том, что при пуше в main вы рискуете доставить в продакшен ошибки. Поэтому создавайте отдельную ветку для разработки и отправляйте её на ревью перед слиянием с main.
Связанная статья: Как писатели могут использовать GitHub для хранения работы
Создание новой ветки через сайт GitHub
Откройте репозиторий в браузере на сайте GitHub. Вы автоматически окажетесь на вкладке “Code”. Немного ниже найдите кнопку с подписью “Main” и нажмите её.
Появится небольшое окно. Введите имя новой ветки в текстовое поле и нажмите Enter (Return). Слова в имени ветки разделяйте дефисом (
-) или символом подчёркивания (
_).
Ветка создана и теперь доступна в репозитории на GitHub.
Связанная статья: Как переключаться между ветками в GitHub
Создание новой ветки через командную строку
Сначала клонируйте репозиторий на локальную машину, если вы этого ещё не сделали. Затем откройте терминал: Terminal на macOS, Command Prompt или PowerShell на Windows, или встроенный терминал в редакторе, например VSCode.
Перейдите в папку с клоном репозитория командой cd. Пример:
cd <файл/путь>
Создайте новую ветку и переключитесь на неё одновременной командой:
git checkout -b <имя-вашей-новой-ветки>Замените <имя-вашей-новой-ветки> на желаемое имя ветки.
Эта ветка создана локально. Чтобы сделать её доступной в удалённом репозитории на GitHub, выполните:
git push origin <имя-вашей-новой-ветки>
После этого ветка появится в репозитории на GitHub, и вы можете создать Pull Request для её проверки и последующего слияния в main.
Работа с ветками — базовый, но ключевой навык в GitHub. Оттачивая его, вы быстро станете эффективнее при совместной разработке.
Связанная статья: Что такое GitHub и для чего он нужен?
Важные рекомендации и лучшие практики
- Выбирайте понятные имена веток: feature/add-login, fix/typo-readme, chore/update-deps.
- Делайте небольшие коммиты и описательные сообщения к ним.
- Часто ребейзьте или мержьте main в ветку, чтобы избегать больших конфликтов.
- Используйте Pull Request для кода, даже если работаете в одиночку: это дисциплинирует и документирует изменения.
- Настройте правила веток (branch protection) для main: требование ревью, зелёные CI-проходы, запрещённые форс-пуши.
Важно: никогда не пушьте секреты (пароли, ключи) в репозиторий. Храните их в секретах CI/CD или менеджере секретов.
Когда подход с веткой может не подойти
- Очень маленькие правки (например, опечатка в README) иногда удобнее править прямо через веб-интерфейс в main, если в репозитории это разрешено и есть проверка.
- Экстренные правки в продакшен (hotfix) требуют продуманного процесса: быстрый PR и ревью, или защищённый доступ к main у ограниченного круга админов.
Альтернативные подходы
- Feature flags: разворачивайте код в main за выключенным флагом, чтобы активировать позже без ветвления.
- Fork-based workflow: используйте fork и PR в upstream — удобно для внешних контрибьюторов.
- Trunk-based development: короткоживущие ветки и частые мерджи в «trunk» для высокочастотной интеграции.
Ментальные модели и эвристики
- Каждая ветка — это «изолированный эксперимент». Не трогайте production, пока эксперимент не доказал свою корректность.
- Малая ветка = быстрый ревью. Большая ветка = риск конфликтов и долгого обзора.
- Название ветки должно отражать цель, не технологию.
Ключевые команды (факты)
- Создать и переключиться: git checkout -b <ветка>
- Отправить на удалённый репозиторий: git push origin <ветка>
- Переключиться на существующую ветку: git checkout <ветка>
- Получить список веток: git branch (локально), git branch -r (удалённые)
Чек-листы по ролям
Разработчик:
- Создать ветку от актуального main.
- Делать мелкие коммиты с понятными сообщениями.
- Подготовить PR с описанием и тестами.
Тимлид/Ревьюер:
- Проверить код на стиль, безопасность и тесты.
- Запросить изменения, если есть риски.
- Быстро мержить маленькие, качественные PR.
Релиз-менеджер:
- Проверить, что все CI-проверки прошли.
- Убедиться в отсутствии незадокументированных изменений.
- Планировать релиз так, чтобы избежать конфликтов.
Простая методология: быстрый SOP для создания ветки
- Обновить локальную main: git checkout main && git pull origin main
- Создать ветку: git checkout -b feature/описание
- Работать и коммитить локально
- Отправить ветку: git push origin feature/описание
- Создать Pull Request и назначить ревьюеров
- Внести исправления, выполнить ребейз/merge main при необходимости
- Слить PR после успешного ревью и CI
Критерии приёмки
- Ветка создана от актуальной main.
- Все тесты проходят в CI.
- Код рассмотрен как минимум одним ревьюером.
- Нет скрытых секретов в коммитах.
Глоссарий (1 строка)
- Ветка: изолированная линия разработки, позволяющая вносить изменения без влияния на основную ветку.
Заключение
Создание веток — простая, но центральная практика при работе с GitHub. Она снижает риск ошибок в продакшене, упрощает ревью и улучшает совместную работу. Освойте команды и процесс, настройте правила для веток и используйте чек-листы, чтобы поддерживать качество проекта.
Важно: перед выполнением операций с удалёнными ветками убедитесь, что у вас есть резервные копии важных изменений и правильные права доступа.
