Gitlab issues как пользоваться

GitLab – ссылки на проблемы

Шаг 1 – Для ссылки на проблему вам необходим номер проблемы созданной проблемы. Чтобы создать проблему, обратитесь к главе « Создание проблемы» .

Шаг 2 – Чтобы увидеть созданную проблему, выберите опцию Список на вкладке Проблемы –

Шаг 3. Прежде чем вносить изменения в локальный репозиторий, проверьте его актуальность или нет, используя приведенную ниже команду:

git checkout master && git pull

Команда git pull загружает последние изменения с удаленного сервера и интегрируется непосредственно в текущие рабочие файлы.

Шаг 4 – Теперь создайте новую ветку с именем fix-fix с помощью команды git checkout –

git checkout -b issue-fix

Шаг 5 – Теперь добавьте некоторый контент в файл README.md, чтобы исправить ошибку –

echo "fix this bug" >> README.md

Шаг 6 – Введите сообщение фиксации для вышеуказанного изменения с помощью команды ниже –

git commit -a

Эта команда открывает приведенный ниже экран и нажимает клавишу « Вставить» на клавиатуре, чтобы добавить сообщение фиксации для ветви с исправлением проблемы .

Теперь нажмите клавишу Esc , затем двоеточие (:) и введите wq для сохранения и выхода с экрана.

Шаг 7 – Теперь отправьте ветку в удаленный репозиторий с помощью команды ниже –

git push origin issue-fix

Шаг 8 – Войдите в свою учетную запись GitLab и создайте новый запрос на слияние. Вы можете обратиться к главе с запросом на слияние для создания запроса на слияние.

Шаг 9. После создания запроса на слияние вы будете перенаправлены на страницу запроса на слияние. Когда вы нажмете кнопку « Закрыть запрос на слияние» (см. Снимок экрана в шаге (6) главы « Запрос на слияние» ), вы увидите опцию «Закрыто» после закрытия запроса на слияние.

4.8 Git на сервере — GitLab

GitWeb довольно-таки прост. Если вам нужен более современный, полнофункциональный Git-сервер, есть несколько решений с открытым исходным кодом, которые можно использовать. Так как GitLab это один из самых популярных, мы рассмотрим его установку и использование в качестве примера. Это немного сложнее, чем GitWeb, и скорее всего потребует больше обслуживания, но и функциональность гораздо богаче.

Установка

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

Другие варианты установки:

• GitLab Helm chart для использования с Kubernetes.
• Официальные образы GitLab для использования с Docker.
• Из исходных файлов.
• Облачный провайдер, такой как AWS, Google Cloud Platform, Azure, OpenShift или Digital Ocean.

Для получения дополнительной информации прочтите GitLab Community Edition (CE) readme.

Администрирование

Административный интерфейс GitLab доступен через веб. Просто направьте ваш браузер на имя или IP-адрес хоста, где установлен GitLab, и войдите как администратор. Имя пользователя по умолчанию admin@local.host , пароль по умолчанию 5iveL!fe (вас попросят изменить их при входе). Войдя, нажмите иконку «Административная зона» в меню справа и сверху.

Рисунок 50. Пункт «Административная зона» в меню GitLab

Пользователи

Пользователи в GitLab — это учётные записи, соответствующие людям. Пользовательские учётные записи не очень сложны; в основном это набор персональной информации, прикреплённый к имени. У каждого пользователя есть пространство имён, логически группирующее проекты данного пользователя. Если у пользователя jane есть проект project, адрес этого проекта будет http://server/jane/project .

Рисунок 51. Экран управления пользователями GitLab

Удаление пользователя может быть выполнено двумя способами. «Блокирование» («Blocking») пользователя запрещает ему вход в GitLab, но все данные в его пространстве имен сохраняются, и коммиты, подписанные этим пользователем, будут указывать на его профиль.

«Разрушение» («Destroying») пользователя, с другой стороны, полностью удаляет его из базы данных и файловой системы. Все проекты и данные в его пространстве имен удаляются, как и все принадлежащие ему группы. Конечно, этим более постоянным и разрушительным действием пользуются реже.

Группы

Группы GitLab — это коллекция проектов с указанием того, как пользователи получают к ним доступ. Каждая группа имеет пространство имён проектов (так же как и пользователи), так что если в группе training есть проект materials, его адрес будет http://server/training/materials .

Рисунок 52. Экран управления группами GitLab

Каждая группа связана с пользователями, каждый из которых имеет уровень доступа к проектам группы и к самой группе. Он разнится от «Гостя» («Guest», только проблемы и чат) до «Владельца» («Owner», полный контроль над группой, её членами и проектами). Типы разрешений слишком обширны, чтобы перечислять их здесь, но на экране управления GitLab есть полезная ссылка с описанием.

Проекты

Проект GitLab примерно соответствует одному git-репозиторию. Каждый проект принадлежит одному пространству имён, групповому или пользовательскому. Если проект принадлежит пользователю, владелец контролирует, кто имеет доступ к проекту; если проект принадлежит группе, действуют групповые уровни доступа для пользователей.

Каждый проект также имеет уровень видимости, который контролирует, кто имеет доступ на чтение страниц проекта или репозитория. Если проект Приватный (Private), владелец должен явно дать доступ на чтение отдельным пользователям. Внутренний (Internal) проект виден любому вошедшему пользователю GitLab, а Публичный (Public) проект видим всем. Это относится как к доступу git fetch , так и к доступу к проекту через веб-интерфейс.

Хуки

GitLab включает поддержку хуков (перехватчиков, hooks) на уровне проектов и всей системы. В обоих случаях, когда происходит некоторое событие, сервер GitLab выполняет запрос HTTP POST с осмысленным JSON-содержанием. Это отличный способ соединить ваши git-репозитории и инсталляцию GitLab с автоматикой инфраструктуры разработки, такой как сервера непрерывной интеграции, комнаты чатов или инструменты деплоя.

Базовое использование

Первое, чего вы захотите от GitLab, это создать новый проект. Это достигается нажатием иконки «+» на панели инструментов. Будут запрошены имя проекта, пространство имён, которому он должен принадлежать, и уровень видимости. Большинство из этих настроек можно потом изменить через интерфейс настроек. Нажмите «Создать проект» («Create Project»), чтобы закончить.

Когда проект создан, вы, наверное, захотите соединить его с локальным git-репозиторием. Каждый проект может быть доступен через HTTPS или SSH, каждый из которых может быть использован для указания удалённого репозитория. Адреса (URL) видимы наверху домашней страницы проекта. Для существующего локального репозитория, следующая команда создаст удалённый репозиторий с именем gitlab и размещением на сервере:

$ git remote add gitlab https://server/namespace/project.git

Если у вас нет локального репозитория, можно просто сделать его:

$ git clone https://server/namespace/project.git

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

Совместная работа

Самый простой метод совместной работы над проектом GitLab — это выдача другому пользователю прямого доступа на запись (push) в git-репозитории. Вы можете добавить пользователя в проект в разделе «Участники» («Members») настроек проекта, указав уровень доступа (уровни доступа кратко обсуждались в Группы). Получая уровень доступа «Разработчик» («Developer») или выше, пользователь может беспрепятственно отсылать свои коммиты и ветки непосредственно в репозиторий.

Другой, более разобщённый способ совместной работы — использование запросов на слияние (merge requests). Эта возможность позволяет любому пользователю, который видит проект, вносить свой вклад подконтрольным способом. Пользователи с прямым доступом могут просто создать ветку, отослать в неё коммиты и открыть запрос на слияние из их ветки обратно в master или любую другую ветку. Пользователи без доступа на запись могут «форкнуть» репозиторий («fork», создать собственную копию), отправить коммиты в эту копию и открыть запрос на слияние из их форка обратно в основной проект. Эта модель позволяет владельцу полностью контролировать, что попадает в репозиторий и когда, принимая помощь от недоверенных пользователей.

Запросы на слияние и проблемы (issues) это основные единицы долгоживущих дискуссий в GitLab. Каждый запрос на слияние допускает построчное обсуждение предлагаемого изменения (поддерживая облегчённое рецензирование кода), равно как и общее обсуждение. И те и другие могут присваиваться пользователям или организовываться в вехи (milestones).

Мы в основном сосредоточились на частях GitLab, связанных с git, но это — довольно зрелая система, и она предоставляет много других возможностей, помогающих вашей команде работать совместно, например вики-страницы для проектов и инструменты поддержки системы. Одно из преимуществ GitLab в том, что, однажды запустив и настроив сервер, вам редко придётся изменять конфигурацию или заходить на него по SSH; большинство административных и пользовательских действий можно выполнять через веб-браузер.

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

Краткое руководство по GitHub Issues

Следуйте этому краткому интерактивному руководству, чтобы узнать о GitHub Issues.

Introduction

This guide demonstrates how to use GitHub Issues to plan and track a piece of work. In this guide, you will create a new issue and add a task list to track sub-tasks. You’ll also learn how to add labels, milestones, assignees, and projects to communicate metadata about your issue.

Prerequisites

To create an issue, you need a repository. You can use an existing repository that you have write access to, or you can create a new repository. The repository must have issues enabled. For more information about creating a repository, see «Creating a new repository.» For more information about enabling issues if they are disabled in your repository, see «Disabling issues.»

Opening a blank issue

First, create an issue. There are multiple ways to create an issue; you can choose the most convenient method for your workflow. This example will use the GitHub UI. For more information about other ways to create an issue, see «Creating an issue.»

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click

Issues.

Filling in information

Give your issue a descriptive title. The title should convey at a glance what the issue is about.

Add a description that explains the purpose of the issue, including any details that might help resolve the issue. For example, if this is a bug report, describe the steps to reproduce the bug, the expected result, and the actual result.

You can use markdown to add formatting, links, emojis, and more. For more information, see «Writing on GitHub.»

Adding a task list

It can be helpful to break large issues into smaller tasks, or to track multiple related issues in a single larger issue. Add a task list to your issue by prefacing list items with [ ] . Reference existing issues by issue number or URL. You can use plain text to track tasks that don’t have a corresponding issue and convert them to issues later. For more information, see «About task lists.»

Adding labels

Add a label to categorize your issue. For example, you might use a bug label and a good first issue label to indicate that an issue is a bug that a first-time contributor could pick up. Users can filter issues by label to find all issues that have a specific label.

You can use the default labels, or you can create a new label. For more information, see «Managing labels.»

Adding milestones

You can add a milestone to track the issue as part of a date based target. A milestone will show the progress of the issues as the target date approaches. For more information, see «About milestones.»

Assigning the issue

To communicate responsibility, you can assign the issue to a member of your organization. For more information, see «Assigning issues and pull requests to other GitHub users.»

Adding the issue to a project

You can add the issue to an existing project and populate metadata for the project. For more information about projects, see «About Projects.»

Submitting your issue

Click Submit new issue to create your issue. You can edit any of the above fields after creating the issue. Your issue has a unique URL that you can share with team members, or reference in other issues or pull requests.

Communicating

After your issue is created, continue the conversation by adding comments to the issue. You can @mention collaborators or teams to draw their attention to a comment. To link related issues in the same repository, you can type # followed by part of the issue title and then clicking the issue that you want to link. For more information, see «Writing on GitHub.»

Next steps

You can use issues for a wide range of purposes. For example:

• Tracking ideas
• Collecting feedback
• Planning tasks
• Reporting bugs

Here are some helpful resources for taking your next steps with GitHub Issues:

• To learn more about issues, see «About issues.»
• To learn more about how projects can help you with planning and tracking, see «About Projects.»
• To learn more about using issue templates and issue forms to encourage contributors to provide specific information, see «Using templates to encourage useful issues and pull requests.»