Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 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)


  1. CodeViking
    24.08.2016 19:49

    Релизы 22 числа каждого месяца? Не спроста они это. Что бы это могло значить?


    1. Sleuthhound
      24.08.2016 20:10
      +1

      22 число — это хорошее число, для меня теперь втройне, 22 июня родился второй сын, 22 июня 1941 началась 2-я мировая — не очень хорошее событие, 22 июня — самый длинный день в году — хорошее событие, а теперь еще и 22 июня нужно обновлять GitLab на кучке обслуживаемых серверов — наверно тоже хорошее событие.


      1. Aingis
        25.08.2016 11:31

        Позанудствую: II мировая началась всё-таки 1 сентября 1939. А 22 июня 1941 года Германия напала на СССР. Самый длинный день тоже всё-таки 21 июня. Вряд ли всем этим руководствовался Гитлаб. А то так и Ульянин день можно вспомнить (день подготовки к празднику Ивана Купалы).


      1. em92
        25.08.2016 12:16

        >22 июня 1941 началась 2-я мировая — не очень хорошее событие
        22 июня 1941 началась Великая Отечественная Война. Вторая мировая — 1 сентября 1939. Их путать — не очень хорошо.


        1. Sleuthhound
          25.08.2016 13:07

          Согласен с Вами на все 100%, 22 июня на СССР напали и началась ВОВ.


    1. nem
      24.08.2016 21:30

      Нет никакой мистики за этим. Экспертов-нумерологов попрошу покинуть чат :)
      Просто так сложилось исторически: https://about.gitlab.com/2015/12/17/gitlab-release-process/#why-monthly-cycles


  1. devpreview
    24.08.2016 20:31

    Issue Board в последнем релизе восхитителен!

    А вот функционал групп, по-моему, неплохо бы расширить.
    Например, добавить туда тот же Issue Board и статистику по коммитам.


    1. nem
      24.08.2016 21:36
      +1

      Спасибо. На 8.12 уже запланирована аналитика, возможно туда упадет и кусок статистики. Я не вникал в детали.


      Что касается issue board — у этой фичи вообще большой потенциал для развития. В 8.11 была только первая итерация работы над issue board. Конкретных планов правда я пока еще не знаю.


      1. hector
        25.08.2016 10:59

        time tracking будет входить в аналитику?


        1. nem
          25.08.2016 11:01

          Пока что это не запланировано, можно поставить плюсик в issue здесь: https://gitlab.com/gitlab-org/gitlab-ee/issues/78


    1. nem
      25.08.2016 12:18

      Вот, кстати, планы насчет развития issue board: https://gitlab.com/gitlab-org/gitlab-ce/issues/21365


  1. easimonenko
    24.08.2016 21:36

    Как у проектов, команд и групп с pages. насколько помню, в github и bitbucket есть, а в gitlab?


    1. nem
      24.08.2016 21:39

      Не совсем понял вопрос. Если вопрос том, есть ли в ГитЛабе аналог GitHub Pages, то да, есть:
      http://pages.gitlab.io и он на самом деле более функциональный чем у ГитХаба(можно юзать любой static site generator + кастомные домены + SSL)
      У Битбакета я кстати не видел этой фичи. Можно ссылку?



  1. nick_volynkin
    25.08.2016 06:56

    Опечатка: "Пееревод".


    1. nem
      25.08.2016 11:02

      Спасибо, поправил!


  1. voe
    25.08.2016 07:52

    каким обращом можно дать пользователю доступ трлько к wiki и issue при этом не давая доступ к исходному коду?


    1. nick_volynkin
      25.08.2016 08:58

      Нужно добавить этого пользователя в группу с ролью Guest. Он сможет создавать тикеты и комментировать, но не получит доступа к коду. Про вики ничего не сказано, стоит проверить на тестовом пользователе. Подробнее: http://docs.gitlab.com/ce/user/permissions.html


      1. voe
        25.08.2016 11:01

        блин. вчера пробовал на общем тестовом проекте… а он с доступом Internal. Оказывается если проект Internal то ограничение для Guest на запрет просмотра кода не действует. С Private проектами все отлично, но не нравится то что ссылки на код остаются а при переходе появляется ошибка 404 что как бы не совсем логично да и не красиво. :)


        1. nick_volynkin
          25.08.2016 12:01

          А не вот эта ли 404 там появляется https://gitlab.com/gitlab-org/gitlab-ce/issues/21425? А вообще, конечно, надо прятать то, на что прав нет, а не 404 показывать.


        1. nem
          25.08.2016 13:50

          а можешь пару скриншотов показать, как это выглядит?


          1. voe
            25.08.2016 15:22

            Кликаем на Files
            http://s019.radikal.ru/i643/1608/9b/344087370280.png
            получаем ошибку —
            http://s020.radikal.ru/i706/1608/c1/33673ef8335e.png


  1. questor
    25.08.2016 23:07

    Статья хорошая, вы выбрали хорошую цель для перевода.