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

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,569 50 50 gold badges 46 46 silver badges 50 50 bronze badges
asked Jul 27, 2022 at 6:28
KansaiRobot KansaiRobot
8,172 14 14 gold badges 83 83 silver badges 161 161 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,077 2 2 gold badges 25 25 silver badges 53 53 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
328 3 3 silver badges 13 13 bronze badges

The Overflow Blog

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.3.2953

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

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

Что такое GitLab

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

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

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

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

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

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

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

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

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

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

Учетная запись готова. Теперь можно переходить непосредственно к знакомству с 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-клиент

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

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

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

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

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

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

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

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

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

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

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.
• Даем имя обнаруженной проблеме, а затем подробно описываем ее в разделе Description.
• Затем назначаем ответственного в пункте Assignee и срок, в течение которого нужно найти решение найденной проблемы.
• А потом нажимаем на кнопку Create issue.

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

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

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

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

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

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

съемка и монтаж: Глеб Лиманский

Git pull

Подключить новых участников к вашему репозиторию можно в меню Settings → Collaborators → Add People.

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

Сымитируем компьютер другого человека, создав вторую папку на нашем компьютере. Назовем ее «Второй участник». Открываем терминал по адресу папки, копируем ссылку на репозиторий на git hub.

Клонируем репозиторий по ссылке: git clone .

Проверим, как называется появившаяся папка с репозиторием: ls.

Заходим в нее: cd git_tutorial.

Включаем отображение веток в терминале: source ~/.zchrc. Подробнее про отображение веток мы рассказывали в прошлом уроке.

Представим, что второй участник решил внести изменения. Он открыл файл в редакторе и добавил в начало кода импорт библиотеки datetime: from datetime import datetime. А последней строкой настроил вывод даты: print(«Today: «, datetime.today().strftime(‘%d/%m/%Y’))

Он коммитит изменения в терминале: git commit -a -m «Add datetime».

Заливает их на Github: git push.

Представим, что мы не знаем, что такие изменения были внесены, и продолжаем работать над проектом локально. Открываем проект в редакторе, добавляем одну строку: print(«Our project: Git_Tutorial»).

Открываем терминал по адресу нашей основной папки Git_Tutorial, в которой начинали работать над проектом. Коммитим изменения: git commit -a -m «Project name».

Пытаемся передать изменения на удаленный репозиторий: git push. Не получается. Git пишет, что версия проекта на нашем компьютере не совпадает с версией на удаленном репозитории. Так получилось, потому что другой участник проекта уже внес какие-то изменения.

Чтобы синхронизировать локальную версию с удаленной, git предлагает команду git pull. Применяем ее: git pull.

Видим сообщение о конфликте в файле test.py.

Чтобы разрешить конфликт, переходим в редактор. Зеленым подсвечены наши изменения, синим — изменения, которые добавил в проект кто-то другой.

VSCode предлагает несколько вариантов, в каком виде сохранить код. В нашей ситуации нам подходит принять все изменения. Выбираем accept both changes. Сохраняем изменения в редакторе.

Коммитим изменения в терминале: git commit -a -m «Add project name». Отправляем на GitHub: git push.

Issues

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

Создадим вкладку issue, чтобы обсуждать изменения в проекте с другими участниками. Нажимаем на зеленую кнопку, пишем название: delete input. Добавляем описание: предлагаю убрать input и переписать первую строку вывода, чтобы не вводить имя каждый раз. Здесь используется тот же язык markdown, как и в файле с описанием проекта README.

В описании можем ссылаться на конкретных людей и на конкретные коммиты, для этого нужно использовать их хэш-код. Можно сослаться и на куски кода. Зайдем в наш файл test.py и выберем строку с запросом информации с клавиатуры, который нам кажется неудобным. Нажмем на три точки рядом с выделенными строками, копируем permalink. Вставим ссылку в issue.

Посмотрим в режиме предпросмотре, как выглядит наш Issue. Если все устраивает, можем нажать submit.

Assignees — на кого назначаем вопрос. Можем выбрать любого участника проекта. В нашем проекте пока только мы, поэтому задача назначится на нас. Если вы назначили задачу на кого-то другого, он увидит уведомление об этом на своей странице Git Hub.

Label — тема нашего issue. Выберем bug. Labels можно настроить под себя.

Project и milestones — проекты и вехи. В рамках одного большого репозитория может быть несколько проектов и вех. Разные issue можно привязывать к этим вехам и проектам. Сейчас мы этот шаг пропускаем.

Pull Requests

В командной работе удобно объединять изменения не на локальном репозитории каждого участника, а на удаленном. Для этого существует функция Pull Request, то есть запрос на изменения. Работа выстраивается так: хотим добавить изменения — создаем в проекте на нашем компьютере ветку, в ветке вносим изменения, коммитим их, отправляем запрос на принятие этих изменений на сервер.

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

Представим, что и мы решили исправить код, как написано в Issue. Откроем терминал. Создадим ветку для изменений del_input и перейдем в нее: git checkout -b del_input.

Перейдем в редактор и удалим input, изменим приветствие. Сохраним изменения.

Вернемся в терминал и закоммитим изменения: git commit -a -m «Delete input». Отправим изменения на сервер. Так как мы отправляем изменения не с основной ветки, обязательно прописать название удаленного репозиторий (origin) и название ветки, с которой отправляем изменения: git push -u origin del_input. Ветка с изменениями появилась на GitHub.

Внесем еще одно изменение. Вернемся в основную ветку: git checkout main. Создадим новую ветку update_test: git checkout -b update_test.

Перейдем в редактор и внесем новые изменения, сохраним их.

Вернемся в терминал и закоммитим изменения: git commit -a -m «Update test».

Отправим изменения на сервер: git push -u origin update_test.

Как только в удаленном репозитории появляется больше одной ветки, Git Hub предлагает объединить изменения из разных веток с помощью функции Pull Request.

Нажимаем compare and pull request. Base — куда мы переносим изменения, compare — откуда. Сначала заберем изменения из ветки del_input в main. Git Hub сам проверяет можно ли сделать слияние без конфликтов и помечает их галочкой. Если видим галочку, значит можно слить ветки без конфликтов.

Можем добавить какое-то описание к слиянию веток, reviewers — участники команды, которым мы даем доступ к этому pull request. Они могут просматривать его и комментировать. В Assignees можем указать, кому именно адресуем запрос на изменения.

Сейчас мы это пропустим и нажмем create pull request.

Нажав на сообщение о коммите, мы можем посмотреть, какие именно изменения предлагаются. Если у нас есть права на подтверждение pull request, мы можем слить две ветки сразу. Сольем две ветки: нажимаем merge pull request.

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

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

Попробуем теперь добавить ветку update_test. Нажимаем compare and pull request.

Ветки автоматически не сливаются, возник конфликт. Все равно создаем запрос на изменения. Решить конфликт можно на странице GitHub. Нажимаем resolve conflict.

Приводим код к нужному виду. Нажимаем mark as resolved → commit merge. Теперь ветки можно слить. Все изменения добавятся в основную ветку.

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