Сопоставляем неоднозначные термины в GitLab, GitHub и Bitbucket

Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 8.10 ^[1], 8.9 ^[2], 8.8 ^[3]

ГитЛаб выпускает релизы 22 числа каждого месяца.
Пееревод поста про релиз 8.11 ^[4] в работе, а пока представляю на ваш суд еще одну статью из блога ГитЛаба про различие терминологии у GitLab, GitHub и Bitbucket.

В зависимости от рабочих задач и потребностей клиентов разработчикам приходится использовать разные платформы управления репозиториями. Типичный разработчик участвует в каком-нибудь открытом проекте на GitHub, а на работе хостит проект одного клиента на GitLab, а другого — в Mercurial и на Bitbucket. Переключения между платформами осложняются тем, что в них одни и те же вещи могут называться совершенно по-разному. В этой статье мы поможем вам сопоставить различия и заодно объясним, почему мы выбрали именно такие названия.

Начиная с версии 8.4 ^[5] в GitLab значительно улучшился процесс миграции репозиториев из GitHub. Теперь GitLab импортирует ^[6] не только репозитории, но ещё и вики-страницы, тикеты и пулл-реквесты. При этом большинство сущностей не меняют своего названия. Например, специфические термины Git, такие как commit или push, везде одинаковы. Не меняются и такие общие термины, как users, webhooks и issues.

Но некоторые термины всё-таки отличаются. Например, то, что в GitHub и Bitbucket называется пулл-реквестом (pull-request), мы называем мерж-реквестом (merge-request). Мы так его назвали, потому что это запрос на merge ветки для выделенной функциональности (feature branch) с мастер-веткой; собственно команда pull там нигде не применяется. К слову, в Git есть отдельная команда request-pull: она тоже позволяет предложить свои изменения и использует-таки команду pull, но имеет совсем другой механизм ^[7].

Если вы только начинаете работать с GitLab, эта таблица поможет вам быстрее освоиться:

Команды, Репозитории и Организации

Давайте разберёмся, чем отличаются команда (team), репозиторий (repository) и организация (organization). В GitHub репозитории содержат собственно репозиторий Git или SVN, а также тикеты (issues), статистику участия и т.п. При этом, пользователи нередко называют репозитории проектами.

В GitLab мы устранили неоднозначность, явно называя такую структуру проектом (project). Проект включает в себя репозиторий Git, тикеты, мерж-реквесты и всё остальное. На странице конфигурации проекта можно:

• Выбрать используемые фичи.
• Установить аватар проекта.
• Настроить уровень видимости проекта: public, internal (для авторизованных пользователей) или private (только для членов группы).
• Переместить, архивировать или удалить проект.
• Настроить использование Gitlab CI в проекте.
• Добавить сервисы для интеграции проекта со сторонними приложениями.

Важно понимать, что даже если вы импортируете в GitLab только чистый репозиторий Git или нечто, что в источнике называется «репозиторием», в результате вы всегда получите проект GitLab.

Важное отличие: в Bitbucket проектом (project) называется объединение нескольких репозиториев. Такие проекты в свою очередь принадлежат командам (teams). В GitHub аналогичную задачу выполняют организации (organizations).

В GitLab такие структуры, объединяющие несколько проектов, называются группами (groups). Пользователи, входящие в группу, получают доступ на чтение, изменение и настройку проектов в зависимости от своей роли в группе. Каждый проект принадлежит только одной группе, но его можно «расшарить» для других групп. Эта фича есть в Gitlab Enterprise Edition, а также в GitLab Community Edition начиная с версии 8.5 ^[8]. Если вы хотите явным образом запретить расшаривание проектов, это можно сделать в настройках группы.

Надеюсь, что эта статья помогла вам лучше разобраться в терминологии. Если у вас ещё остались вопросы, задавайте их в комментариях.

Автор: Softmart

Источник ^[9]