Для команды из трёх разработчиков с приватным репозиторием выбор платформы GitHub или GitLab сводится к одному: где именно обязательный проходящий тест и одно обязательное одобрение до слияния реально работают на доступном тарифе. Облачный GitLab на Free-плане даёт одобрения необязательными, поэтому жёсткое условие закрывает Premium и Ultimate. GitHub требует подходящего плана для защиты приватных веток. Ниже — разбор по первичной документации и заполненная матрица.
Что именно сравниваем: три разных предмета
Сравнение «GitHub или GitLab» смешивает три сущности, и от этого путаются выводы. Облачный GitHub — управляемый сервис, где защита веток настраивается правилами branch protection. Облачный GitLab — тоже управляемый сервис, но с другой моделью тарифов: часть функций контроля доступа к веткам и одобрений привязана к уровню подписки. GitLab Self-Managed — установка на своём оборудовании, отдельное техническое решение со своей эксплуатацией.
В документации GitHub раздел о защищённых ветках описывает правила, которые задают, может ли участник удалять ветку или делать force push, и какие требования предъявляются к пушам, включая прохождение status checks. В документации GitLab страница о защищённых ветках перечисляет уровни Free, Premium, Ultimate и варианты размещения: GitLab.com, Self-Managed, Dedicated.
Различие важно для команды: облачные платформы дают готовую инфраструктуру, а Self-Managed переносит администрирование на вас. Запрос на собственное развёртывание в учебном наборе отсутствует, поэтому Self-Managed остаётся справочным вариантом, который стоит рассматривать отдельно от выбора между облачными сервисами.
Учебный набор: что должна уметь платформа
Зафиксируем входные условия, от которых считаем выбор. Это учебный паспорт задачи. Измерения продукта редакция не проводила.
- Приватный репозиторий.
- Три разработчика.
- Основная ветка main.
- Изменения проходят только через pull request (GitHub) или merge request (GitLab).
- До слияния обязателен проходящий тест.
- До слияния обязательно одно одобрение.
- Запроса на собственное развёртывание нет.
Эти условия жёсткие: если хотя бы одно не выполняется на доступном тарифе, платформа не подходит. Одобрение здесь обязательное, и его нельзя подменять необязательным. В документации GitLab прямо сказано: на Free-плане одобрения доступны пользователям с ролью Developer и выше, но они необязательны и не блокируют слияние. Обязательные правила одобрения относятся к Premium и Ultimate.
Для GitHub ключевое условие — тариф и видимость репозитория. В документации GitHub указано: защищённые ветки доступны в публичных репозиториях на GitHub Free и GitHub Free для организаций, а в публичных и приватных репозиториях — на GitHub Pro, GitHub Team, GitHub Enterprise Cloud и GitHub Enterprise Server. Приватный репозиторий выводит команду на платные уровни.
Контрольный коммит и эталон проверки
Чтобы проверка была воспроизводимой, возьмём минимальный коммит. Функция add(a, b) возвращает a + b. Тест add(2, 3) == 5 проходит. Ошибочный вариант, где функция возвращает a — b, даёт FAIL.
def add(a, b):
return a + b
def test_add():
assert add(2, 3) == 5
Ошибочный вариант для проверки блокировки:
def add(a, b):
return a - b
def test_add():
assert add(2, 3) == 5
Эталон приёмки согласован так: зелёный тест и одобрение — слияние может разрешаться; красный тест и одобрение — слияние заблокировано; зелёный тест без одобрения — слияние заблокировано. Две проверки из набора, которые нужно пройти на выбранной платформе: зелёный тест с одобрением и красный тест с одобрением. Если красный тест с одобрением всё равно сливается, обязательный status check не настроен.
Матрица выбора: условия, тариф, видимость
| Обязательное условие | GitHub (облако) | GitLab (облако) | Зависимость от тарифа и видимости | Место проверки в первичке |
|---|---|---|---|---|
| Защита ветки main | Есть | Есть | GitHub: приватные репозитории требуют Pro/Team/Enterprise; GitLab: Free, Premium, Ultimate | Документация GitHub и GitLab о защищённых ветках |
| Обязательный проходящий тест | Required status checks | Правила ветки + CI | GitHub: required status checks настраиваются в правиле защиты | Документация GitHub, раздел о required status checks |
| Одно обязательное одобрение | Required reviews | Required approvals | GitLab: обязательные одобрения относятся к Premium/Ultimate; Free даёт необязательные | Документация GitLab о merge request approvals |
| Только через PR/MR | Правило защиты ветки | Allowed to push and merge = No one | GitLab: при разрешённом push можно обойти MR | Документация GitLab о защищённых ветках |
| Приватный репозиторий | Платный уровень | Free поддерживает приватность | GitHub: приватность требует плана для защиты веток | Документация GitHub о защищённых ветках |
| Self-Managed | Не рассматривается | Отдельное решение | Своя эксплуатация | Документация GitLab о размещении |
Перед расчётом бюджета команда проверяет актуальный тариф и фактический объём CI. До этого ценовой победитель для учебной заявки остаётся неопределённым.
Условная рекомендация и когда её пересматривать
Если команда готова платить за уровень, где обязательное одобрение работает, оба облачных кандидата проходят. Выбор тогда определяется удобством процесса и уже используемыми инструментами.
Если бюджет ограничен Free-планом, GitLab не закрывает обязательное одобрение: на Free одобрения необязательны. GitHub на Free закрывает защиту веток только для публичных репозиториев, а у команды репозиторий приватный. Значит, бесплатный вариант не проходит жёсткое условие ни там, ни там.
Пересматривать рекомендацию стоит при смене одного из условий: если обязательное одобрение перестанет быть обязательным, Free-план GitLab станет допустимым; если репозиторий станет публичным, у GitHub откроется защита веток на Free. Пока условия жёсткие, ориентируйтесь на тариф, где обязательное одобрение подтверждено документацией.
Проверка GitHub: защита веток и status checks
В документации GitHub сказано: администраторы репозитория или роли с правом редактирования правил могут требовать, чтобы все pull request получали определённое число одобряющих ревью до слияния в защищённую ветку. Одобрения могут исходить от людей с правом записи или от назначенного code owner.
Отдельно проверьте required status checks. В документации GitHub указано: обязательные проверки статуса должны иметь статус successful, skipped или neutral, прежде чем участники смогут вносить изменения в защищённую ветку. Если обязательные проверки не включены, участники могут слить ветку в любой момент, независимо от актуальности относительно базовой ветки, что повышает риск несовместимых изменений.
Для приватного репозитория вернитесь к тарифу: защита веток в приватных репозиториях доступна на GitHub Pro, Team, Enterprise Cloud и Enterprise Server. Проверьте, что ваш план входит в этот список, иначе правило защиты просто негде включить.
Проверка GitLab: ветки и одобрения
В документации GitLab защищённые ветки управляют тем, кто может сливать и пушить изменения, предотвращают случайное удаление критичных веток и регулируют требования к одобрению. Настроить их можно в разделе Settings > Repository > Branch rules. Для защиты ветки нужна роль Maintainer или Owner.
Ключевой момент для условия «только через merge request»: в документации GitLab описаны две настройки — Allowed to merge и Allowed to push and merge. Если оставить разрешённый прямой push, участник с этим правом может обойти одобрение merge request. Чтобы изменения шли только через MR, установите Allowed to push and merge в значение No one. В документации GitLab приведена конфигурация для активных веток разработки: Allowed to merge — Developers + Maintainers, Allowed to push and merge — No one.
По одобрениям: на Free-плане одобрения необязательны и не блокируют слияние. Обязательные правила одобрения относятся к Premium и Ultimate. Не выдавайте Free за обязательное одобрение: для учебного условия нужен уровень, где правило одобрения действительно блокирует слияние.
Администраторы и CODEOWNERS: что проверить отдельно
Правила для доверенных администраторов и CODEOWNERS не выполняются автоматически независимо от плана. В документации GitHub сказано: по умолчанию ограничения правила защиты ветки не применяются к людям с правами администратора репозитория или к кастомным ролям с правом обхода защиты веток. Применить ограничения к администраторам можно опционально.
В документации GitLab указано: при защите ветки можно включить требование одобрения от code owners. Само наличие файла CODEOWNERS не гарантирует обязательного выполнения — нужно включить соответствующую опцию в правиле.
Практический вывод: если в команде есть администратор, проверьте, распространяется ли на него правило защиты. Иначе обязательное одобрение можно обойти на уровне прав, и учебное условие не выполняется фактически.
План проверки для читателя
Это план, который вы выполняете сами на своей платформе. Редакция интерфейс не запускала и платных запросов не делала.
- Создайте приватный репозиторий и убедитесь, что ваш тариф допускает защиту веток.
- Защитите ветку main.
- Включите обязательный проходящий тест (required status checks в GitHub, CI-проверку в GitLab).
- Включите одно обязательное одобрение (required reviews в GitHub, required approvals в GitLab Premium/Ultimate).
- В GitLab установите Allowed to push and merge в No one, чтобы изменения шли только через MR.
- Закоммитьте вариант с add(a, b) = a + b, откройте PR/MR, получите одобрение, убедитесь, что слияние разрешено.
- Закоммитьте вариант с a — b, получите одобрение, убедитесь, что слияние заблокировано.
- Проверьте, применяется ли правило к администратору репозитория.
Если шаг 7 не блокирует слияние, обязательный тест не настроен. Если шаг 4 недоступен, ваш тариф не закрывает обязательное одобрение.
Частые вопросы
Что выбрать для команды из трёх разработчиков с приватным репозиторием?
Оба облачных варианта подходят, если тариф закрывает обязательное одобрение. У GitLab это Premium или Ultimate, у GitHub — план, допускающий защиту приватных веток. На Free-плане GitLab обязательное одобрение недоступно.
Работает ли обязательное одобрение в GitLab Free?
На Free-плане одобрения доступны пользователям с ролью Developer и выше, но они необязательны и не блокируют слияние. Обязательные правила одобрения относятся к Premium и Ultimate. Для жёсткого условия нужен платный уровень.
Нужен ли платный план GitHub для защиты веток?
Для публичных репозиториев защита веток доступна на GitHub Free. Для приватных репозиториев нужен GitHub Pro, Team, Enterprise Cloud или Enterprise Server. У команды с приватным репозиторием выбор сводится к платным уровням.
Можно ли обойти обязательное одобрение прямым пушем?
В GitLab при разрешённом Allowed to push and merge участник может обойти одобрение merge request. Установите это значение в No one, чтобы изменения шли только через MR. В GitHub администраторы по умолчанию обходят ограничения защиты веток, если их не применить явно.
Заменяет ли CODEOWNERS обязательное одобрение?
Нет. В GitLab требование одобрения от code owners включается отдельной опцией в правиле защиты ветки. Само наличие файла CODEOWNERS обязательного выполнения не даёт. Проверьте, что опция включена и применяется к нужным файлам.