Assignee gitlab кого указывать

gitlab merge request. Who is the assignee?

There is one particular point I don’t understand for GitLab’s merge requests. I cloned a repository and made a feature branch. I worked something on it, committed it, and pushed the new branch to my GitLab repo. With that I can make a merge request. When I do it says: Assignee (and Assign to me) Who should I assign it to? I mean, if I assign it to me, it is going to be me who «reviews» the change and approves it, so what is the point? Or should I assign it to the repository administrator? Or to other member reviewers, so that they can check that and approve the merge? What is the «Assign to me» option, and how does that makes sense?

5,583 50 50 gold badges 46 46 silver badges 50 50 bronze badges
asked Jul 27, 2022 at 6:28
KansaiRobot KansaiRobot
8,240 14 14 gold badges 85 85 silver badges 163 163 bronze badges

3 Answers 3

There is documentation for that. It states:

This person owns the merge request, but isn’t responsible for reviewing it.

Additionally, the documentation explains an exemplary merge request workflow:

1. You would typically create the MR before working on your feature branch.
2. Then you can use the Assign to me feature to indicate that you are the one currently working on implementing the features of the MR.
3. After your work is done you can request a review following these guidelines.
4. After finishing the review you can fall back to step 8 in the MR workflow.

answered Jul 27, 2022 at 6:45
YoshiMbele YoshiMbele
809 1 1 silver badge 13 13 bronze badges

Oh, you are talking about the WIP right? where you work on the feature branch before requesting to merge it

Jul 27, 2022 at 7:18

«After your work is done you can request approval from a reviewer by assigning the MR» Then why does gitlab have a «Reviewer» Field in the merge request form? Also as I read this correctly, your statement disagrees with the other answer? Where the other answer says the field should not be used for reviewers?

Sep 26, 2023 at 13:54

@ChefLax I have rewritten my answer and added additional documentation based explanation to hopefully clear up some of the points. Yes you are right the assignee and the reviewer should not be the same person, I had that wrong in my earlier revision.

Sep 27, 2023 at 8:16

The people who are assigned to a merge request are the people who are responsible for it, not in a review kind of sense.
Usually it is the person who creates the pull request who counts as responsible for it i.e. has the responsibility of merging when all reviewers are happy and have approved or making changes according to the reviewers comments.

However, multiple people can have this responsibility as it is not always prudent for this to rest on a single person (what if the person goes on vacation?). Another case is if multiple developers have been working on the same feature and therefor have shared responsibility for the code in the merge request.

TL;DR Multiple people can have responsibility / can be accountable for the merge request.

answered Jul 27, 2022 at 6:44
Lars Nielsen Lars Nielsen
2,088 2 2 gold badges 25 25 silver badges 54 54 bronze badges

What I have experienced in practice and also what can be seen when reading through the other answers to this question is that while there might be a predefined idea from gitlab on how to use this field, many teams use this feature differently. It is best to ask your team/company how they use this field.

What I have seen when working is this workflow:

1. you create a MR, you assign the reviewer as asignee
2. now he reviewed, he assigns you as the asignee
3. then you handle his review comments and then assign him as assignee again, since he should now take a final look at the MR and possibly approve it

answered Sep 27, 2023 at 7:55
Felix Olszewski Felix Olszewski
414 5 5 silver badges 13 13 bronze badges

Featured on Meta

Related

Hot Network Questions

Subscribe to RSS

Question feed

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2024 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2024.1.26.3951

GitLab для начинающих: зачем он нужен в мире, где есть GitHub

Статья рассчитана на читателей, которые уже хотя бы немного знакомы с Git. Изучить основы работы с системой контроля версий можно бесплатно в большом курсе Хекслета.

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

Что такое GitLab и зачем он нужен

GitLab — сервис для хранения и управления Git-репозиториями. Как и его более известный конкурент, GitHub, он значительно облегчает коллективный труд разработчиков, позволяя им писать и редактировать код, а также его тестировать и развертывать без лишних проблем.

Работать с GitLab можно по-разному: как через командную строку, Web IDE (встроенный IDE для работы в браузере), так и через сторонние Git-клиенты. Скажем сразу, правильного способа нет: каждый работает, как ему удобно, в зависимости от задач и доступных устройств.

GitLab vs GitHub

Существенных различий между GitLab и GitHub на самом деле практически нет. Разве что:

• GitLab — проект с открытым исходным кодом, поэтому сообщество может улучшать платформу. На GitHub эта возможность доступна только разработчикам.

С 2018 года владельцем GitHub является компания Microsoft, что, учитывая репутацию этого гиганта, было воспринято сообществом неоднозначно. Тем не менее популярность GitHub выше, чем у GitLab: у платформы не было конкурентов с 2008 года. О GitLab тогда еще мало кто знал — он появился только в 2011 году, а активно развиваться начал далеко не сразу.

Что выбрать начинающему разработчику?

Оба сервиса хорошо справляются с большинством задач разработки, однако:

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

А вот для веб-разработки подойдут оба проекта: для этих целей у обоих есть свои Pages. Держите ссылки на них для GitLab и для GitHub .

Читайте также: Как правильно составлять описания коммитов и почему это важно

Ключевые особенности GitLab

• Совместимость. Гитлаб поддерживает интеграцию с популярными платформами и сервисами — Docker, Kubernetes, Jira, сервисы от Google, а также имеет инструментарий для совмещения практически с любыми приложениями. Это означает, что GitLab может быть легко интегрирован и в корпоративную среду.
• Метки и документация. Удобная система меток, которая значительно упрощает процесс разработки, позволяя классифицировать ошибки или запросы. Также с ее помощью можно отслеживать изменения, выполняемые по своим или чужим проектам. Система документации на Гитлабе выстроена так, что каждый проект документируется в отдельном репозитории.
• Гибкие настройки доступа. Доступ к репозиториям настраивается в соответствии с группой, в которой находится пользователь. Закрытые ветки создаются с использованием встроенного модуля, который позволяет настраивать права для каждого пользователя. И благодаря собственной системе защиты от киберугроз GitLab предлагает безопасную аутентификацию.
• Удобный импорт и экспорт данных. Сервис позволяет легко импортировать большие объемы данных из разных источников. Это обеспечивается за счет интеграции с популярными решениями, например, Jira. Также пользователям доступны инструменты для синхронизации кода.
• Kubernetes по умолчанию для развертывания. Удобное решение для тех, кто занимается разработкой и тестированием приложений, поскольку Kubernetes — самый популярный оркестратор в среде контейнеризации.
• Выделенное пространство в облаке. GitLab предлагает всем пользователям бесплатное размещение проектов в облаке. Кроме того, в GitLab можно бесплатно создавать частные репозитории для хранения открытого кода.
• Инструменты аналитики и планирования. Аналитические инструменты Гитлаба позволяют отслеживать время, затраченное на каждую задачу, планировать дальнейшую работу, отслеживать активность каждого разработчика. А инструмент Burndown Chart понравится тем, кто использует в разработке метод спринтов.
• Регулярные обновления. Гитлаб обновляется каждый месяц, причем значительное внимание уделяется удобству и безопасности работы.

GitLab Runner

GitLab Runner — полезный веб-инструмент для выполнения инструкций файлов репозиториев. Устанавливать GitLab Runner необходимо тем, кто собирается выполнять настройку CI/CD собственного проекта. Но в первую очередь нужно установить Docker — платформу контейнеризации, с помощью которой выполняется создание образов и развертывание контейнеров.

GitLab CI/CD

CI/CD — технология непрерывной интеграции и доставки. CI/CD помогает автоматизировать и масштабировать проекты, что значительно сокращает время разработки. GitLab CI/CD — инструмент, который позволяет превратить Гитлаб в полноценную платформу для DevOps со всеми необходимыми функциями.

GitLab CI/CD обеспечивает управление конфигурациями через yaml-файлы, стабильный запуск в различных средах, сборку и выполнение в разных операционных системах. Кроме того, с помощью этого инструмента можно выполнять интеграцию с кластерами Kubernetes и работать с задачами в окружениях Docker.

Дальше мы предсказуемо сравним GitLab CI/CD со схожим по функциям инструментом Гитхаба — GitHub Actions.

GitLab CI/CD vs GitHub Actions

Чтобы при переходе с GitHub Actions на GitLab CI/CD у новичка не возникло трудностей, рассмотрим основные различия между этими инструментами.

1. В CI/CD скрипты в заданиях выполняются с помощью ключа script , а в Actions для этого используется ключ run .
2. Задания на разных платформах в CI/CD выполняются с помощью ключа tags , а в Actions — с помощью runs-on .
3. Оба инструмента могут работать с заданиями в образах Docker, а также указывать дополнительные контейнеры, для чего в CI/CD используется ключ image , а Actions — container .
4. При выполнении заданий с условиями CI/CD использует ключ rules , а Actions — if .
5. Для выполнения заданий с зависимостями в CI/CD есть ключ stages , а в Actions используется needs .

Посмотреть примеры кода для каждого сервиса, а также узнать о некоторых менее существенных расхождениях можно в официальной документации GitHub по этой теме. И, хотя инструкция называется «Миграция с GitLab CI/CD на GitHub Actions», она подойдет и при переходе с Actions на CI/CD.

Читайте также: Как присоединиться к работе над опенсорсом, что такое PS1 и другие вопросы: отвечает разработчик Хекслета Андрей Мошков

Немного практики: первый проект на GitLab

Чтобы создать проект на GitLab, нужно выполнить несколько несложных шагов:

• Создать учетную запись и рабочую группу
• Создать репозиторий
• Загрузить файлы
• Добавить ключи авторизации.

Теперь о каждом из этих шагов подробнее.

Создание учетной записи и рабочей группы на GitLab

После нажатия на кнопку Login на сайте проекта появится кнопка регистрации. Кликнув на нее, вы перейдете в форму, где нужно будет заполнить ряд стандартных полей, а затем подтвердить регистрацию из письма, которое сервис отправит на указанный email.

После успешного создания учетной записи приступаем к настройке GitLab. Для этого переходим в свой профиль и заполняем нужные поля, включая имя группы. Также вас попросят указать, будете ли вы работать в одиночку или в составе команды.

Создание репозитория в GitLab

После создания группы в верхней панели появится иконка с плюсиком: кликните на выпадающее меню рядом и выберите пункт New project или New project/repository . Далее выбираем уровень приватности. Если не хотите, чтобы ваш код был виден другим пользователям и вообще никому, кроме вас, выберите из выпадающего меню уровень Private . Теперь можно приступать к загрузке файлов в репозиторий Git, который будет сформирован вместе с проектом.

Загрузка файлов в GitLab

Файлы загружаются одним из трех способов:

• Через веб-интерфейс нажатием на кнопку Upload File
• Через командную строку при помощи программы git
• Через сторонний Git-клиент, например, Sublime Merge или Tower.

Можно также использовать и Web IDE, предназначенный для работы в браузере.

Добавление ключей авторизации

Для генерации ключа понадобится ввести в терминале команду ssh-keygen , при этом директорию, где будут храниться ключи, можно оставить по умолчанию. Далее сервис предложит ввести пароль, а затем скопировать ключ из папки (его можно узнать по расширению .pub) и вставить его на сайте GitLab: нажмите на пункт SSH-keys в меню слева. Узнать больше об установке Git вы можете, изучив наши инструкции .

Дальнейшая работа

Первичная настройка GitLab на этом завершена. Теперь можно приступать к работе с ветками проекта, добавлять новых пользователей и делать многие другие вещи (например, отправлять баг-репорты). Приведем основные полезные функции:

• Для создания новой ветки перейдите в репозиторий, откройте уже знакомое по внешнему виду меню с плюсиком и выберите пункт New Branch . Те, кто пользуется git-клиентами, могут сделать то же самое командой git checkout или с помощью графического интерфейса
• Для объединения веток проекта в одну (этот процесс называется мерджинг или слияние) нажмите на кнопку Create merge request и заполните необходимые поля. Потребуется написать поясняющий комментарий, указать автора запроса, проверяющего и поставить теги, после чего подтвердить слияние
• Добавление новых пользователей осуществляется через левое меню. Выберите там Project information и далее Members . В открывшейся форме, помимо ника и электронной почты, укажите роль пользователя и дату, когда срок действия его прав истечет, и он будет исключен из проекта. Это время всегда можно продлить.
• Для оповещений коллег и пользователей о каких-либо проблемах — чаще всего это баги или ошибки, — выберите в левом меню пункт Issues . Далее по клику на кнопку New Issue , откроется форма, где нужно будет указать название и добавить описание проблемы, а также назначить ответственного — Assignee .

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

Gitlab merge request

Gitlab merge request — позволяет перед коммитом в master ветку отправить внесенные изменения другим разработчикам проекта, это аналог pull request в git. merge request позволяет предотвратить внесение некорректных изменений, которые сломают проект.

Gitlab merge request: как сделать и принять MR

Зайдя в Gitlab от имени пользователя, который может работать с проектом скачаем исходный код через git clone

ip адрес в примере используется для демонстрации, его нужно заменить на свой.

git clone git@ip-address:root/myproject.git

Теперь на локальном компьютере присутствуют скрипты проекта, или один скрипт index.py как в примере.

Переходим в каталог

Теперь можно создать новую ветку

В ней вносим изменения

Открыв файл в текстовом редакторе добавим комментарий

Затем добавляем все содержимое каталога на staging

И заливаем в ветку update-code

Total 3 (delta 1), reused 0 (delta 0)
remote: To create a merge request for update-code, visit:
remote: http://ip-address/root/myproject/merge_requests/new?merge_request%5Bsource_branch%5D=update-code
remote:
To ip-address:root/myproject.git
* [new branch] update-code -> update-code

После обновления страницы в интерфейсе Gitlab будет отображаться вторая ветка

Рядом с именем ветки есть кнопка Merge request

При нажатии на нее открывается диалог позволяющий задать описание, добавить комментарий, установить Milestone и выбрать кому из разработчиков будет отправлен MR.

Также можно установить, что нужно чье-либо одобрение для принятия Merge-request и слияния с веткой master.

После заполнения полей формы нужно нажать Submit merge request внизу.

Теперь тот кому отправлен MR получит оповещение и сможет увидеть все внесенные изменения, затем закрыть MR, выполнить слияние с master или начать дискуссию.

В интерфейсе есть кнопки Open in Web IDE и Check out branch

Нажатие на первую позволит увидеть разницу до и после внесения изменений, код будет выводиться на экране разделенном на две части вертикально. Аналогично git diff.

Если выбрать Check out branch — отобразится инструкция с командами, позволяющими скачать изменений на локальный компьютер, исправить все конфликты и загрузить в репозиторий.

В случае если изменения корректны и не нанесут ущерба проекту можно нажать Merge.

В консоли когда merge выполнен, можно переключиться на master и забрать через pull изменения.

Изменения будут залиты в master. Найдя MR всегда можно воспользоваться опцией revert для отмены.

Читайте про Gitlab Wiki и документацию к проектам в Gitlab

¶ Group overview

Details — подраздел Group overview, куда вы попадаете, как только откроете группу вашего проекта. На этой страничке находится три вкладки:

• subgroups и projects — репозитории с файлами, созданными участниками проекта
• shared projects — репозитории других проектов, куда дали доступ всей вашей команде
• archived projects — архивированные репозитории, которые доступны только для чтения.

Там же находится кнопка New project, с помощью которой можно создать новый репозиторий.

¶ Activity

Activity — это журнал активности участников проекта. В нем отображаются все изменения, внесенные в ваш проект с указанием на их автора.

¶ Issues

Issues — это основная среда для совместной работы над идеями и планирования работы в GitLab. Они позволяют обмениваться предложениями и обсуждать их до и во время их реализации между вами и вашей командой или сторонними авторами. Issues всегда привязаны к одному из ваших репозиториев в проекте, однако в разделе List вы будете видеть все Issues вашего проекта.

Этим разделом участники пользуются нечасто, потому что функцию трекинга исполняют сервисы Trello и Taiga.

¶ List

В этом подразделе вы можете создавать Issues — обсуждение задачи с командой. Чтобы создать обсуждение, нажмите «New issue» и заполните информацию о задаче, которую вы собераетесь совместно решать: опишите ее и добавьте нужные файлы. В боковом меню справа вы можете найти вкладку Labels и добавить метку: выбрать из списка предложенных или создать собственную с помощью кнопки «Create project labels». Теперь ваше обсуждение будет выглядеть вот так:

issue с метками

¶ Labels

Labels — это метки для issue. Они могут отражать статус задачи или использоваться для сортировки обсуждений.

Если вы перейдете в этот подраздел, то увидите, что по умолчанию уже создано две метки: «To do» и «Doing». Вы можете создать собственные метки:

1. для этого нажмите на кнопку «New label»
2. введите название метки и выберите цвет для нее
3. нажмите кнопку «Create label»

Чтобы установить метку на issue вернитесь в редактирование issue в подразделе List. В боковом меню справа вы можете найти вкладку Labels и добавить только что созданную вами метку.

¶ Boards

Здесь расположен Kanban: доска с колонками по умолчанию «Open», «To Do», «Doing» и «Closed». Все новые issues сразу попадают в колонку «Open». Если вы перетащите левой кнопки мыши ваше обсуждение в другую колонку, то в подразделе «List» около обсуждение появится метка, соответствующая названию колонки на доске.

Чтобы добавить новую колонку, создайте новую метку в подразделе «Labels». Затем вернитесь в Boards и нажмите на кнопку «Add list». Поставьте галочку напротив только что созданной метки, и на доске появится одноименная колонка.

¶ Milestones

Milestones позволяют создавать спринты, или циклы, в период которых отслеживаются issues и merge requests.

Чтобы создать новую Milestones, нажмите на кнопку «New milestones» и введите заголовок, добавьте описание и установите приблизительные сроки для исполнения.

¶ Merge Requests

Merge request — это запрос на слияние веток. Необходимость использования этой функции может возникнуть тогда, когда нужно перенести функциональность из одной ветки в другую.

1. В разделе Merge Requests» нажмите на New Merge Request» для создания нового запроса на слияния одной ветки с другой.
2. Выберите ветку, из которой хотите добавить изменения (в нашем случае development). В качестве «Target branch» выберите нужную вам ветку (у нас это master).
3. Затем нажмите на кнопку «Compare branches and continue«.

1. Если не возникло конфликтов, на новой странице задайте заголовок, описание и в поле Assignee выберите своего руководителя.

Рекомендуем вам делать при слиянии веток сквош: объединять коммиты. Это помогает избежать путаницы и длинного списка коммитов. Для этого просто поставьте галочку около пункта «Squash commits when merge request is accepted». Далее нажмите на кнопку «Merge».

¶ Members

В этом разделе руководитель проекта может добавить участников в проект.

1. Для этого попросите сначала авторизиваться студента на сайте GitLab через корпоративную почту с доменом @miem.hse.ru.
2. Затем в графе GitLab member or Email address введите имя пользователя и выберите его из списка.
3. Укажите роль участника.
   • Developer(рекомендумая) — разработчик, имеет право на создание и редактрирование репозиториев, обсуждений, меток.
   • Guest — гость, не имеет право на редактирование, может только просматривать файлы.
   • Reporter — ограничены правы редактирования. Например, не может создавать новые ветки и делать merge requests
   • Maintainer — имеет расширенные права управления проектом. Может удалять репозитории.
4. Нажмите Invate.

¶ Project Overview

После того, как вы откроете один из репозиториев вашего проекта, количество вкладок в боковом меню увеличится. Первой вкладкой будет раздел Project Overview.

¶ Details

В этом подразделе хранятся все файлы выбранного репозитория и основная информация о нем. Здесь же находится кнопка Clone, с помощью которой можно узнать URL репозитория для копирования его на свой компьютер.

Чтобы создать папку, файл, ветку или загрузить новый файл с компьютера, нажмите на плюс в левом верхнем углу.

Если хотите переключиться на другую ветку, нажмите на ее название в левом верхнем углу и выберите нужную.

подраздел Details

¶ Activity

Activity — это журнал активности участников проекта. В нем отображаются все изменения, внесенные в выбранный репозиторий с указанием на их автора.

¶ Repository

¶ Files

Этот подраздел аналогичен подразделу Details: здесь тоже хранятся все файлы выбранного репозитория, находится кнопка Clone, плюс и возможность переключаться между ветками.

подраздел Files

¶ Commits

Здесь хранится история коммитов выбранного репозитория:

подраздел Commits

¶ Branches

В этом подразделе хранится список веток выбранного репозитория. Чтобы перейти на нужную ветку, просто щелкните по ней.

¶ Contributors

Здесь вы можете увидеть общее количество коммитов и количество коммитов каждого участника проекта в выбранном репозитории.

¶ Graph

График репозитория визуально отображает историю изменений в выбранном репозитории:

подраздел Graph

¶ Compare

Если в репозитории несколько веток, то их можно сравнить, чтобы увидеть изменения.

¶ CL / CD

GitLab CI / CD — это встроенный в GitLab инструмент для разработки программного обеспечения с использованием непрерывных методологий :

• continuous integration(CI)
• continuous delivery (CD)
• continuous deployment (CD)

Continuous integration работает путем отправки небольших фрагментов кода в базу кода вашего приложения, размещенную в репозитории Git, и при каждом нажатии запускает конвейер сценариев для создания, тестирования и проверки изменений кода перед их объединением в основную ветвь.

Continuous delivery и deployment состоят из следующего шага CI, направляющего ваше приложение в ветку master репозитория при каждом пуше.

Эти методологии позволяют обнаруживать ошибки на ранних этапах разработки.

¶ Pipelines, Jobs and Schedules

Pipelines — это компонент верхнего уровня continuous integration, delivery и deployment.
Pipelines включают:

1. Jobs, которые определяют, что делать. Например, задания по компиляции или тестированию кода.
2. Stages, которые определяют, когда запускать задания. Например, этап, на котором выполняются тесты, запускается после этапа компиляции кода.

Как правило, pipeline выполняются автоматически и после создания не требуют вмешательства. Однако бывают случаи, когда вы можете вручную взаимодействовать с pipeline.

¶ Уровень видимости проекта

Каждый проект имеет уровень видимости, который контролирует, кто имеет доступ на чтение страниц проекта или репозитория.

Уровни видимости:

• Приватный (Private) проект — владелец должен явно дать доступ на чтение отдельным пользователям. Редактировать его могут только участники проекта.
• Внутренний (Internal) — проект виден любому вошедшему пользователю GitLab. Редактировать его могут только участники проекта. Наблюдатели могут разветвить этот проект, внести в него изменения и отправить запрос на слияние.
• Публичный (Public) — проект видим всем, редактировать его могут только учатники проекта. Наблюдатели могут разветвить этот проект, внести в него изменения и отправить запрос на слияние.

¶ Как изменить уровень видимости?

Уровень видимости может изменить только создатель проекта.

1. Сначала нужно изменить видимость группы.

• Шаг 1. Зайдите на страницу вашего проекта в GitLab;
• Шаг 2. В боковой панеле найдите Settings (Настройки), General (Общие);

• Шаг 3. Измените уровень видимости на тот, который вам нужен.

• Шаг 4. Нажмите Save changes (Сохранить изменения).

1. Теперь нужно изменить видимость репозитория.

• Шаг 1. Откройте на странице проекта в GitLab нужный репозиторий;
• Шаг 2. В боковой панеле найдите Settings (Настройки), General (Общие);

• Шаг 3.Permissions (Разрешения). Измените уровень видимости на тот, который вам нужен.

• Шаг 4. Нажмите Save changes (Сохранить изменения).

Пожалуйста, устновите видимость группы и репозитория Public перед защитой проекта!