Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Определите ожидаемый путь изменения
Небольшая команда привыкла отправлять изменения прямо в main, а после нескольких неудачных релизов хочет перейти к проверке через pull request. Сначала договоритесь о поведении: кто может создавать ветки, кто проверяет код и кто завершает слияние. Отдельно перечислите автоматические инструменты, которые обновляют версии или формируют релизы. Защита ветки должна поддерживать этот процесс. Одно ограничение без договорённости о рецензировании не улучшит качество кода. Начните с одного репозитория и выберите спокойное окно, когда нет срочного релиза и можно проверить как успешные действия, так и ожидаемые отказы.
Проинвентаризируйте текущие правила
В Bitbucket Cloud правила branch permissions могут задаваться для конкретной ветки и шаблона. Если main совпадает с несколькими правилами, нужно учитывать их совместное действие. Поэтому сначала сохраните текущие настройки, включая wildcard-правила, исключения пользователей и используемые группы. Проверьте точное название основной ветки и связанные release-ветки. Не переносите правила из другого репозитория без анализа: там могут работать иные технические пользователи. Составьте таблицу действий: прямой push, создание pull request, merge и удаление ветки. Для каждого определите допустимых исполнителей и отдельно укажите поведение автоматизации.
Настройте ограничения небольшим шагом
Откройте настройки репозитория и актуальный раздел branch permissions. Добавьте правило для main и настройте допустимый маршрут изменения по согласованной модели. Не объединяйте ввод ограничений с массовой сменой участников workspace. Для дополнительных проверок merge изучите доступные настройки конкретного репозитория и их фактическое поведение. Рекомендация команды требовать успешную сборку должна быть подтверждена тем, что соответствующая проверка реально блокирует выбранное действие. Сохраните исходные настройки и ссылку на заявку. После изменения не приступайте сразу к следующему репозиторию: сначала выполните матрицу проверки пилота.
Проверьте обычного разработчика и автоматизацию
Под ролью разработчика попробуйте отправить небольшой учебный коммит напрямую в защищённую ветку и убедитесь, что происходит ожидаемый отказ. Затем создайте рабочую ветку, pull request и пройдите правильный маршрут слияния. Для проверки используйте безопасное изменение документации в пилотном репозитории. Отдельно запустите автоматический процесс обновления версии, если он должен продолжить работать. Не выдавайте боту полный административный доступ только потому, что узкое действие отказало. Определите недостающий маршрут и минимальные права. Проверьте также пользователя, который состоит одновременно в нескольких группах: его фактические полномочия могут отличаться от ожидаемых.
Опишите аварийный маршрут заранее
Инцидент не должен становиться поводом бесконтрольно снять все ограничения. Согласуйте, кто вправе принять срочное изменение, какие проверки обязательны даже в аварии и как фиксируется решение. Если исключение действительно необходимо, ограничьте его временем и конкретным действием. После восстановления сервиса выполните обычное рецензирование и верните исходную защиту. Для изменения схемы репозитория предусмотрите откат настроек из сохранённой таблицы. Сам откат branch permissions не откатывает уже попавший в main код. При неудачном коммите нужен отдельный проверенный Git-процесс с учётом общей истории и развёрнутого приложения.
Проверьте процесс после первого релиза
После одного полного цикла разработки спросите команду, где ограничения помогли, а где заблокировали допустимое действие. Разберите каждый обход: возможно, не описан процесс релиза или автоматизация использует неподходящую идентичность. Не ослабляйте защиту всей ветки из-за одного неудобного инструмента. Поддерживайте небольшой реестр правил и их назначения, обновляя его при смене модели ветвления. Повторяйте отрицательные проверки после изменений настроек и групп. Хороший результат — воспроизводимый безопасный путь от ветки до релиза, понятный разработчику и дежурному. Количество включённых переключателей само по себе таким результатом не является.
Таблица допуска для первого релиза
Перед вводом защиты составьте таблицу для четырёх субъектов: обычный разработчик, ответственный за слияние, автоматизация релиза и пользователь только с чтением. Для каждого перечислите допустимые и запрещённые действия. Проверьте прямой push, открытие pull request и изменение защищённой ветки тем способом, который реально использует команда. Особое внимание уделите технической идентичности: её название не доказывает, какие права она получила. Если проверка обнаружила неожиданный успех запретного действия, остановите внедрение и разберите пересечение правил. Не скрывайте проблему дополнительной устной договорённостью. После исправления повторите весь набор, потому что новое правило может изменить поведение другого субъекта. Сохраните результаты в репозитории или связанном эксплуатационном документе без секретных значений. Такая таблица помогает безопасно обновлять настройки через полгода, когда исходные участники уже не помнят, зачем были введены отдельные исключения.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу