Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8
ГитЛаб выпускает релизы 22 числа каждого месяца.
Пееревод поста про релиз 8.11 в работе, а пока представляю на ваш суд еще одну статью из блога ГитЛаба про различие терминологии у GitLab, GitHub и Bitbucket.
В зависимости от рабочих задач и потребностей клиентов разработчикам приходится использовать разные платформы управления репозиториями. Типичный разработчик участвует в каком-нибудь открытом проекте на GitHub, а на работе хостит проект одного клиента на GitLab, а другого — в Mercurial и на Bitbucket. Переключения между платформами осложняются тем, что в них одни и те же вещи могут называться совершенно по-разному. В этой статье мы поможем вам сопоставить различия и заодно объясним, почему мы выбрали именно такие названия.
Начиная с версии 8.4 в GitLab значительно улучшился процесс миграции репозиториев из GitHub. Теперь GitLab импортирует не только репозитории, но ещё и вики-страницы, тикеты и пулл-реквесты. При этом большинство сущностей не меняют своего названия. Например, специфические термины Git, такие как commit или push, везде одинаковы. Не меняются и такие общие термины, как users, webhooks и issues.
Но некоторые термины всё-таки отличаются. Например, то, что в GitHub и Bitbucket называется пулл-реквестом (pull-request), мы называем мерж-реквестом (merge-request). Мы так его назвали, потому что это запрос на merge
ветки для выделенной функциональности (feature branch) с мастер-веткой; собственно команда pull
там нигде не применяется. К слову, в Git есть отдельная команда request-pull
: она тоже позволяет предложить свои изменения и использует-таки команду pull
, но имеет совсем другой механизм.
Если вы только начинаете работать с GitLab, эта таблица поможет вам быстрее освоиться:
Bitbucket | GitHub | GitLab | Что это означает |
---|---|---|---|
Pull Request | Pull Request | Merge Request | В GitLab запрос на мерж ветки в master назвается мерж-реквестом |
Snippet | Gist | Snippet | Версионируемый фрагмент кода. Уровень видимости: public, internal или private |
Repository | Repository | Project | Проект — это структура, включающая в себя репозиторий Git, настройки, обсуждения и другие сопутствующие инструменты |
Teams | Organizations | Groups | В 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. Если вы хотите явным образом запретить расшаривание проектов, это можно сделать в настройках группы.
Надеюсь, что эта статья помогла вам лучше разобраться в терминологии. Если у вас ещё остались вопросы, задавайте их в комментариях.
Автор: Softmart