Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 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. Если вы хотите явным образом запретить расшаривание проектов, это можно сделать в настройках группы.
Надеюсь, что эта статья помогла вам лучше разобраться в терминологии. Если у вас ещё остались вопросы, задавайте их в комментариях.
Переводчик: nick_volynkin
Комментарии (23)
devpreview
24.08.2016 20:31Issue Board в последнем релизе восхитителен!
А вот функционал групп, по-моему, неплохо бы расширить.
Например, добавить туда тот же Issue Board и статистику по коммитам.nem
24.08.2016 21:36+1Спасибо. На 8.12 уже запланирована аналитика, возможно туда упадет и кусок статистики. Я не вникал в детали.
Что касается issue board — у этой фичи вообще большой потенциал для развития. В 8.11 была только первая итерация работы над issue board. Конкретных планов правда я пока еще не знаю.
hector
25.08.2016 10:59time tracking будет входить в аналитику?
nem
25.08.2016 11:01Пока что это не запланировано, можно поставить плюсик в issue здесь: https://gitlab.com/gitlab-org/gitlab-ee/issues/78
nem
25.08.2016 12:18Вот, кстати, планы насчет развития issue board: https://gitlab.com/gitlab-org/gitlab-ce/issues/21365
easimonenko
24.08.2016 21:36Как у проектов, команд и групп с pages. насколько помню, в github и bitbucket есть, а в gitlab?
nem
24.08.2016 21:39Не совсем понял вопрос. Если вопрос том, есть ли в ГитЛабе аналог GitHub Pages, то да, есть:
http://pages.gitlab.io и он на самом деле более функциональный чем у ГитХаба(можно юзать любой static site generator + кастомные домены + SSL)
У Битбакета я кстати не видел этой фичи. Можно ссылку?
voe
25.08.2016 07:52каким обращом можно дать пользователю доступ трлько к wiki и issue при этом не давая доступ к исходному коду?
nick_volynkin
25.08.2016 08:58Нужно добавить этого пользователя в группу с ролью Guest. Он сможет создавать тикеты и комментировать, но не получит доступа к коду. Про вики ничего не сказано, стоит проверить на тестовом пользователе. Подробнее: http://docs.gitlab.com/ce/user/permissions.html
voe
25.08.2016 11:01блин. вчера пробовал на общем тестовом проекте… а он с доступом Internal. Оказывается если проект Internal то ограничение для Guest на запрет просмотра кода не действует. С Private проектами все отлично, но не нравится то что ссылки на код остаются а при переходе появляется ошибка 404 что как бы не совсем логично да и не красиво. :)
nick_volynkin
25.08.2016 12:01А не вот эта ли 404 там появляется https://gitlab.com/gitlab-org/gitlab-ce/issues/21425? А вообще, конечно, надо прятать то, на что прав нет, а не 404 показывать.
CodeViking
Релизы 22 числа каждого месяца? Не спроста они это. Что бы это могло значить?
Sleuthhound
22 число — это хорошее число, для меня теперь втройне, 22 июня родился второй сын, 22 июня 1941 началась 2-я мировая — не очень хорошее событие, 22 июня — самый длинный день в году — хорошее событие, а теперь еще и 22 июня нужно обновлять GitLab на кучке обслуживаемых серверов — наверно тоже хорошее событие.
Aingis
Позанудствую: II мировая началась всё-таки 1 сентября 1939. А 22 июня 1941 года Германия напала на СССР. Самый длинный день тоже всё-таки 21 июня. Вряд ли всем этим руководствовался Гитлаб. А то так и Ульянин день можно вспомнить (день подготовки к празднику Ивана Купалы).
em92
>22 июня 1941 началась 2-я мировая — не очень хорошее событие
22 июня 1941 началась Великая Отечественная Война. Вторая мировая — 1 сентября 1939. Их путать — не очень хорошо.
Sleuthhound
Согласен с Вами на все 100%, 22 июня на СССР напали и началась ВОВ.
nem
Нет никакой мистики за этим. Экспертов-нумерологов попрошу покинуть чат :)
Просто так сложилось исторически: https://about.gitlab.com/2015/12/17/gitlab-release-process/#why-monthly-cycles