linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
Intro
Lessons
Footer
linuxlab-УчебникиЦеныО платформеКонфиденциальность и куки
Copyright © 2026 LinuxLab. Все права защищены.
linuxlab.io
Учебники▾
  • Линукс и сети
    Файловая система, процессы, TCP/IP, BGP и OSPF
    →
  • Terraform и IaC
    HCL, state, plan/apply на sandbox LocalStack
    →
  • Git и GitHub
    Объектная модель, plumbing, ветвление, GitHub Actions
    →
Все учебники →
ЦеныО платформеВойтиСоздать аккаунт
/
  • Введение
  • Главы
  • How it works
  • Уроки
  • База знаний
  • Собеседование
home/git/kb/Совместная работа/branch-protection

kb/collab ── Совместная работа ── intermediate

Branch protection rules

Набор правил, которые GitHub/GitLab/Bitbucket применяет к попыткам изменить защищённую ветку. Запрещает прямой push, требует PR с approve, требует зелёный CI, блокирует force-push. Без них любой с write-доступом может затереть main одним коммитом.

view as markdownaka: branch-protection-rules, protected-branch

Branch protection - серверная защита ветки от прямых изменений и force-push. Настраивается в Settings -> Branches на GitHub (на GitLab это «Protected branches», на Bitbucket - «Branch restrictions»). Без неё ветка отличается от любой другой только именем; с ней - попытка push'а проверяется по правилам, и отказывается, если правила нарушены.

Что включать на main

Минимальный набор для рабочего репо:

  • Require a pull request before merging - запрещает прямой push, можно только через merge PR.
  • Require approvals (минимум 1) - один из других членов команды должен поставить approve.
  • Dismiss stale pull request approvals when new commits are pushed - после нового коммита approve'ы сбрасываются. Защищает от «получил approve, добавил пятьсот строк, смерджил».
  • Require status checks to pass - выбранные jobs CI должны быть зелёными.
  • Require conversation resolution - все review-комментарии должны быть resolved.
  • Do not allow bypassing the above - админы тоже подчиняются правилам. Без галки protection превращается в рекомендацию.
  • Allow force pushes и Allow deletions - оставляй выключенными. В UI это именно тумблеры «разрешить»: включишь - защищённая ветка теряет защиту от перезаписи и удаления.

Опциональные опции

  • Require linear history - запрещает merge-коммиты, только squash или rebase. Вопрос вкуса команды.
  • Require signed commits - все коммиты подписаны (gpg-signing). На security-чувствительных репо.
  • Require review from Code Owners - в связке с codeowners блокирует merge без approve от owner'а изменённого пути.
  • Restrict who can push - явный список людей/teams.

Что блокируется

Без bypass'а защищённая ветка отказывает на:

  • git push origin main (прямой push)
  • git push --force origin main (force-push)
  • git push origin --delete main (удаление)
  • merge PR, не удовлетворяющий правилам

Подводные камни

  • Settings -> Branches доступны только admin'ам репо. Если ты не admin, попросить настроить может только owner.
  • Status checks становятся required по имени. Если ты переименовал CI workflow - старое имя осталось «required», но не запускается. Зайди в branch protection и обнови.
  • Protection на pattern, не на конкретной ветке. Можно защитить release/* целиком.
  • На GitLab аналог называется «Protected branches», на Bitbucket - «Branch restrictions». Концепция одинаковая, опции немного разные.

§ команды

bash
gh api repos/:owner/:repo/branches/main/protection

Посмотреть текущие правила protection через GitHub API

bash
gh api -X PUT repos/:owner/:repo/branches/main/protection -f required_pull_request_reviews[required_approving_review_count]=1

Программно установить required approvals=1 через API

§ см. также

  • codeownersCODEOWNERSФайл `.github/CODEOWNERS` привязывает пути в репо к командам или людям. При открытии PR, который трогает эти пути, владельцы автоматически назначаются ревьюверами. В связке с branch protection блокирует merge без их approve.
  • pull-requestPull Request (PR)Запрос на влитие ветки в основную с прохождением ревью и CI. На GitHub/GitLab/Bitbucket - стандартный механизм совместной работы. Технически это не команда Git, а функция хостинга, надстроенная над веткой и серией коммитов.
  • force-pushForce push`git push --force` затирает удалённую историю своей. `git push --force-with-lease` делает то же, но отказывает, если кто-то успел запушить туда после твоего последнего fetch. Используй всегда `--force-with-lease`.
Footer
linuxlab-
Copyright © 2026 LinuxLab. Все права защищены.
Учебники
Цены
О платформе
Конфиденциальность и куки