Assignee gitlab что это
Перейти к содержимому

Assignee 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 перед защитой проекта!

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

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. 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,573 49 49 gold badges 45 45 silver badges 50 50 bronze badges
asked Jul 27, 2022 at 6:28
KansaiRobot KansaiRobot
7,954 12 12 gold badges 80 80 silver badges 160 160 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
787 1 1 silver badge 12 12 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 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 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,035 2 2 gold badges 25 25 silver badges 52 52 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 at 7:55
Felix Olszewski Felix Olszewski
176 2 2 silver badges 13 13 bronze badges

    The Overflow Blog

sponsored post

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 © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.11.29.1725

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Как работать с GitLab

Как работать с GitLab

Сегодня поговорим об азах взаимодействия с одной из самых популярных git-систем.

Что такое GitLab

Сейчас почти никто не пишет код в одиночку. Команды инженеров и разработчиков растут, как на дрожжах. Работая в группах, программисты используют системы управления исходным кодом на базе git, специального инструмента, позволяющего хранить данные разрабатываемого проекта в сети и совместно редактировать его с учетом определенных правил и методик взаимодействия. Самый известный подобный сервис – GitHub. А GitLab – это его собрат, выполняющий те же функции, но устроенный несколько иначе.

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

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Разница между GitLab и GitHub

Оба сервиса – системы управления репозиториями на базе git. Принципиальных отличий между ними нет. GitHub появился раньше и стал чуть ли не синонимом git, поэтому он популярнее и для многих является единственной системой для управления репозиториями.

Но GitLab есть что предложить с точки зрения функциональности, поэтому все чаще наблюдается переход пользователей с GitHub на GitLab. В частности, это касается разработчиков-новичков, которые пока еще не «приросли» к GitHub.

В связи с растущей популярностью GitLab я и решил познакомить вас с этим сервисом поближе.

Инструкция по использованию GitLab

Перед началом работы с сервисом, нужно создать учетную запись. Процедура эта весьма тривиальна:

  • Заходим на официальный сайт GitLab.
  • В верхнем левом углу находим кнопку Login и жмем по ней.
  • Через пару секунд перед вам откроется форма входа в систему, а под ней будет ссылка на форму регистрации (Register now). Переходим по ней. Кнопка регистрации в GitLab
  • Заполняем данные для регистрации (классические данные: адрес электронной почты, пароль, логин и т.п.). Жмем на кнопку Register.
  • В течение пары минут на указанную при регистрации почту «упадет» сообщение со ссылкой для подтверждения создания аккаунта. Переходим по ней. Письмо подтверждения регистрации от GitLab

Учетная запись готова. Теперь можно переходить непосредственно к знакомству с GitLab.

Как создать проект

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

Экран создания новой группы

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

После формирования проекта можно переходить непосредственно к созданию репозиториев, загрузке программ в GitLab и т.п.

Как создать репозиторий

Чтобы воспользоваться репозиторием, нужно создать новый проект:

  • Кликаем по иконке со значком + в панели управления. Кнопка создания нового репозитория в GitLab
  • Выбираем пункт New project/repository.Пункт
  • Затем кликаем по Create blank project.
  • Указываем его имя и другие запрашиваемые параметры (можно указать, публичным будет репо или приватным) и нажимаем на кнопку Create Project.

Вместе с проектом сформируется новый git-репозиторий. Теперь можно с ним взаимодействовать, то есть загружать файлы, делать коммиты, создавать различные ветки для разработки продукта и мерджить их при необходимости.

Как загрузить файлы сайта/приложения в GitLab

Тут есть 3 пути.

Первый – используем веб-интерфейс GitLab
  • На главной странице проекта ищем строку The repository for this project is empty, а под ней кнопку Upload File и нажимаем на нее.
  • GitLab предложит выбрать файлы проекта для загрузки и последующей работы с ними. Выбираем все файлы, что используем при разработке и выгружаем.

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

Второй – используем командную строку

Тут все сложнее, но на самом GitLab опубликована короткая и доходчивая инструкция по подключению к сервису через командную строку, используя классический git-клиент.

Инструкция по работе с git

Третий – используем сторонний git-клиент

Существуют приложения в духе Tower и Sublime Merge, позволяющие управлять репозиториями, делать коммиты и пушить изменения в проекты при помощи удобного графического интерфейса. Можно подключиться к GitLab с помощью одной из таких программ.

Как добавить SSH-ключ для подключения к репозиторию

SSH-ключи можно использовать для авторизации в GitLab и для управления репозиториями по протоколу Secure Shell. Чтобы это сделать:

  1. Генерируем ключ с помощью команды ssh-keygen (вводим ее в терминал). Интерфейс генератор SSH-ключей
  2. Генератор предложит сохранить получившийся ключ. Менять директорию, куда сохраняется ключ, необязательно. Папка для сохранения SSH-ключа
  3. Затем утилита попросит ввести пароль. Его тоже можно не вводить. Просто жмем на Enter. Запрос на ввод пароля для SSH-ключа
  4. В указанной на втором этапе папке появится файл с ключом в формате .pub. В нем лежит ключ. Нужно скопировать его.
  5. Возвращаемся на сайте GitLab. Открываем раздел SSH-keys, вставляем ключ в специально отведенное для этого поле и нажимаем на кнопку Add key. Интерфейс для ввода SSH-ключей в GitLab

Как работать с ветками

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

По умолчанию в GitLab доступна только одна ветка – master. Но ее чаще используют не для разработки, а для публикации готовых сборок проекта, которые нестрашно превратить в релиз для масс.

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

Как создавать ветки

Ветки – не уникальная для GitLab функция. Это часть git, поэтому, как и в случае с репозиториями, тут можно пойти тремя путями:

Кнопка создания дополнительной ветки в GitLab

  1. На сайте GitLab в окне управления репозиторием нажать на кнопку + справа от названия ветки, а потом выбрать пункт New branch в выпадающем меню.
  2. Можно создать новую ветку через git-клиент в терминале с помощью команды git checkout -b [название новой ветки].
  3. Или воспользоваться аналогичной функций в используем графическом git-клиенте (Tower, Sublime Merge, GitFox и т.п.).

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

Мерджинг веток

Мерджинг (или объединение) веток – это механизм слияния двух наборов функций одной программы, позволяющий переносить функции из дополнительных веток в основную ветку разработки, где лежит приложение. Результат увидят еще и пользователи, а не только разработчики.

Запрос на объединение веток будет появляться на сайте GitLab каждый раз, когда вы будете вносить изменения в код одной или нескольких веток.

Выглядит это следующим образом:

Кнопка создания запроса на объединение веток

  • На сайте появляется большая синяя кнопка Create merge request. Кликаем по ней.
  • Затем рассказываем о своем запросе (поясняем, для чего он делается).
  • Указываем автор запроса в поле Assignee.
  • Указываем человека, который будет проверять запрос в поле Reviewer.
  • Потом указываем Milestone (если используете их).
  • Ставим теги.
  • И нажимаем на Create merge request.
  • Если с запросом все ок, то проверяющий нажмет на кнопку Merge, и весь код перекочует в основную ветку проекта (ну или ту, которую указал автор запроса).

Как добавлять пользователей в проект

К разработке своего приложения/сайта всегда можно привлечь людей со стороны:

Интерфейс добавления новых пользователей к репозиторию

  • Для этого кликаем по кнопке Project information в боковой панели GitLab.
  • Выбираем пункт Members.
  • В графу GitLab member or Email address вписываем ник GitLab-пользователя или его email-адрес.
  • Выбираем для него роль (гость, наблюдатель, разработчик).
  • Также указываем время действия приглашения (в указанный день приглашенный будет исключен из проекта).
  • А потом кликаем на Invite.

Если выбранный человек согласится присоединиться, то ваша команда расширится.

Как создавать баг-репорты

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

Речь идет о разделе Issues. Если возникла проблема, то нужно сообщить о ней тут. Для этого:

  • Открываем раздел Issues в боковой панели управления.
  • Затем нажимаем на кнопку New issue. Кнопка создания нового issue
  • Даем имя обнаруженной проблеме, а затем подробно описываем ее в разделе Description.
  • Затем назначаем ответственного в пункте Assignee и срок, в течение которого нужно найти решение найденной проблемы.
  • А потом нажимаем на кнопку Create issue. Интерфейс создания нового issue

Как удалить проект

  • Открываем настройки проекта и переходим во вкладку General.
  • Листаем ее до пункта Advanced и справа от него ищем кнопку Expand, которая откроет доступ к дополнительным параметрам.
  • Вновь пролистываем появившееся меню до упора вниз, пока не наткнемся на кнопку Delete project.
  • Нажимаем на нее и вписываем название проекта, чтобы его удалить.

Вместо заключения

На этом все. Я рассмотрел базовые возможности GitLab и намеренно не затрагивал аналитические инструменты, интеграцию с Kubernetes и дополнительные функции, пытаясь сконцентрироваться на важнейших концептах GitLab и git. Это то, что вам необходимо для старта, независимо от того, пользовались вы ранее другими системами управлениями репозиториями или нет.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *