Как создать Merge Request?
Всем доброго дня. В ТЗ на стажировку попросили отправить ссылку на merge request:
«Выполнив задачу вы создаёте merge request в основную ветку вашего репозитория. Ссылку на этот merge request прикрепляете в ответ на задачу.»
Как правильно это нужно сделать? Проект залил на GitHub, но дальше этого никуда не ушло. Где-то писали, что нужно сделать форк репозитория, но у меня эта кнопка на странице проекта неактивна, так как я являюсь владельцем этого репозитория (так там пишет). В Git я полный ноль пока что, так что очень прошу объяснить как для полного нуба.
- Вопрос задан 03 мая 2023
- 309 просмотров
4 комментария
Простой 4 комментария
сделать merge request на GitLab через Git bash
и дальше как создать merge request? на сайте GitLab’a https://docs.gitlab.com/ee/user/project/push_options.html перепробовал все команды и никакого эффекта.
Отслеживать
задан 27 фев 2021 в 18:10
352 1 1 серебряный знак 14 14 бронзовых знаков
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
На ГитЛаб сайте не нашел этой инфы, нашел в инете :
1. git pull 2. git checkout - b test 3.git add . 4.git commit -m 'explanation what is changed' 5.git request-pull master origin 6.git push -o merge_request.create -o merge_request.remove_source_branch Отслеживать
ответ дан 27 фев 2021 в 18:57
352 1 1 серебряный знак 14 14 бронзовых знаков
- gitlab
- git-merge
-
Важное на Мете
Похожие
Подписаться на ленту
Лента вопроса
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.1.26.3951
Изучаем Git. Урок 24.
Мердж-реквесты и код-ревью
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое мердж-реквест?
Это запрос на вливание одной ветки в другую. Чаще всего вливается ваша ветка в мастер — основную ветку разработки
Зачем нужны мердж-реквесты?
В первую очередь они нужны при работе в команде для проведения код-ревью. Чтобы коллеги увидели новый код и как минимум его просмотрели и оставили замечания или вопросы
Как правильно: merge request или pull request?
Это одно и то же. В github и bitbucket используется понятие pull request, в gitlab — merge request. Я буду использовать мердж реквест, думаю, так звучит точнее. Вы же говорите как угодно, все поймут, о чем речь
Как проходит процедура мердж-реквеста
- 1. Мы готовим ветку с новым функционалом/правкой бага/рефакторингом
- 2. Пушим ветку на github
- 3. В интерфейсе github открываем мердж-реквест, выбираем, какую ветку и куда хотим смерджить (чаще всего в мастер), при необходимости указываем описание мердж-реквеста и ревьюеров — тех, кто будет смотреть наш код
- 4. Сообщаем коллегам о новом мердж-реквесте
- 5. Коллеги смотрят код, оставляют замечания или вопросы
- 6. Обсуждение: мы смотрим замечания, соглашаемся на правки или возражаем, объясняем, почему мы сделали именно так
- 7. Делаем правки, пушим в ту же ветку новые коммиты
- 8. Резолвим все вопросы, чтобы все замечания были закрыты или поправлены
- 9. Принимаем мердж-реквест, при этом ветка сливается в мастер
- 10. Удаляем ветку разработки, при необходимости деплоим в продакшен
Немного о markdown
Markdown — это специальная разметка для форматирования текста. Очень удобна в комментариях на github в описаниях к мердж-реквесту или в комментариях к коду
Markdown позволяет форматировать текст: задавать заголовки, списки, цитаты, вставлять ссылки и картинки и даже форматировать код. Насчет кода, возможно, для приграммиста это самая удобная фишка markdown, так как используется достаточно часто
Изучается markdown быстро, разметка очень простая. Вот пример оформления списка, используются звездочки
А вот пример оформления кода, используются апострофы
После этого ваш текст красиво отформатируется, можете попробовать в любом markdown онлайн-редакторе, например, dillinger.io/
Совет от автора
Потратьте немного времени на изучение markdown. Уйдет полчаса-час, но знание очень пригодится в дальнейшем. Markdown много где используется, комментарии на github — это просто одна из сфер его применения. Также с помощью markdown создают readme и даже пишут целые статьи для блогов
Немного о код ревью
Это отдельная большая тема и git она не касается. Поэтому приведу только кратко причины проводить код ревью
- Коллеги узнают о новом коде, попадающем в master
- Подскажут, как лучше организовать код
- Возможно, найдут ошибки
- Предложат лучшее решение или алгоритм
- Проверят соглашения, принятые при оформлении кода
Вопросы на код ревью могут быть совершенно разные и на разные темы. Это всего лишь краткий перечень плюсов от код ревью
2 года назад я написал статью о код-ревью: Две истории про Фёдора и Лёху
И я до сих пор не изменил своего мнения относительно код-ревью 🙂
Как оповестить коллег о новом мердж-реквесте
Здесь разные варианты, зависит от договоренностей в команде.
- Одни предпочитают автоматизировать все что можно и настраивают уведомления в корпоративные мессенджеры или на почту.
- Вторые пишут в личку нужным людям
- Третьи кричат на весь офис «Ребят, гляньте мой мердж-реквест срочна!»
- Четвертые совмещают все способы
Главное договориться как будет удобнее всем в вашей команде
Кто принимает мердж-реквесты
Здесь тоже могут быть разные варианты:
- Принимает автор кода, он же сразу после мерджа деплоит мастер в прод
- Принимает один из ревьюеров, так как за ним окончательное решение — мерджить ветку или нет
- Принимает тимлид, потому что он биг босс
- Принимает тестировщик, например, потому что только он умеет деплоить в прод
Немного о работе в команде
Гит и вообще разработка — это командная игра. Во многих вопросах нет правильных и неправильных решений, есть подходящие для вашей команды, для вашей ситуации
Поэтому делайте так, как удобнее вам, а не так, как пишут эксперты из айти-тусовки. Брать за основу опыт умных людей — да. Слепо копировать чужие подходы — нет. Пробуйте, экспериментируйте, договаривайтесь в своей команде, находите варианты, которые устраивают всех. И так, постепенно, вы придете к лучшим практикам, найдете оптимальные решения для вашей команды
Нет оптимальных решений, которые подходят всем.
Есть оптимальные для ваших условий и вашей команды. И эти решения вам придется выбирать самим
Полезные ссылки
Спасибо за внимание и до встречи!
Все уроки курса
- Вводный урок
- 1. Установка и базовая настройка git
- 2. Создание и клонирование репозитория git
- 3. Делаем первые изменения, git status и git diff
- 4. Коммиты и история коммитов, git commit, git log и git show
- 5. Подробнее об истории коммитов. Путешествие по истории
- 6. Работа с сервером, git push и git pull
- 7. Ветки — главная фишка git, git branch и git checkout
- 8. Работа с ветками на сервере, git fetch
- 9. Слияния или мерджи веток, git merge
- 10. Конфликты и их разрешение
- Платная часть курса. Презентация
- * 11. Работа с gitignore и git exclude
- * 12. Буфер обмена git, git stash
- * 13. Копирование коммитов, git cherry-pick
- * 14. Отмена и редактирование последнего коммита
- * 15. Отмена произвольного коммита, git revert
- 16. Склеивание коммитов, git rebase —interactive и git reflog
- * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
- * 18. Работа с git rebase. Отличия от merge
- * 19. Что такое git push —force и как с ним работать
- * 20. Ищем баги с помощью git, git bisect
- * 21. Как и зачем работать с тегами git
- * 22. Процессы: github flow и git flow
- * 23. Псевдонимы в git
- 24. Мердж-реквесты
- * 25. Форки
Как создать запрос на слияние (Merge request) в Gitlab
В данной статье рассмотрим пример как влить свои изменения в чужую ветку Gitlab.
В прошлой статье мы рассмотрели как отправлять свои изменения в свою ветку Gitlab, но что если мы работаем в команде и имеется удаленная ветка в репозитории, куда все программисты (и не только) складывают конечные результаты своей работы, т.е. вливают свои изменения (коммиты) в чужую ветку, которую (условно) все считают конечной веткой. У такой удаленной ветки пусть будет главный хозяин, которые принимает чужие изменения или наоборот — требует доработать, т.е. выполняет ревью коммитов. Рассмотрим простую схему для лучшего понимания.
Предварительные действия:
Все действия будут показаны на примере среды разработки Idea Intellij в которой работают тестировщики и пишут тест-кейсы на java. Далее каждый тестировщик отправляет изменения из своей ветки в конечную ветку develop.
Idea Intellij удобна тем, что там имеется встроенный инструмент GIT, т.е. не приходится отдельно работать в менеджере git или в консоли git bash.
01 Создадим новую ветку из ветки «develop», чтобы потом в нее влить только новые коммиты, которые будут нами созданы. Для этого (на примере все той же Idea Intellij), нужно перейти на вкладку «Git» слева в нижней части окна программы, встать на ветку develop и нажать на «+» -> указать имя ветки и нажать Enter:
Таким образом мы создадим новую ветку с именем «new_branch» на основании ветки «develop».
02 Работаем с новой веткой «new_branch», делаем нужные изменения, коммитим их, отправляем (git push) в ветку «new_branch». При этом локальная ветка«new_branch» созданная на основании «develop» создастся не только локально, но и на сервере репозитория.
03 Создадим запрос на слияние «Merge request» с веткой «develop» коммитов из ветки «new_branch». Для этого переходим на сайт Gitlab и ищем в меню кнопку и на новой открывшейся странице найдем кнопку создания запроса выберем ветки слияния:
1. В форме «Source branch» выбрать ветку, из которой слить изменения (коммиты).
2. В форме «Target branch» выбрать ветку, в которую нужно влить изменения (коммиты).
3. Нажать кнопку «Compare branches and continue».
04 Далее добавить описание запроса на слияние:
1. «Заголовок» — краткое описание вливаемых изменений.
2. «Discription» — описание выполненной работы.
05 Далее зарегистрировать запрос на слияние:
1. «Отвественный» — ответственный за выполнение задачи («Assign to me» — назначить меня)
2. «Reviewer» — ответственный за проверку (хозяин ветки «develop»)
3. Чек-бокс «Delete source branch when merge request is accepted» — означает, что вливаемая ветка «new_branch» будет удалена из репозитория. Локально она останется у нас на ПК. Эта галочка полезна, чтобы не засорять репозиторий лишними ветками.
4. Нажать кнопку «Create запрос на слияние».
06 Создан новый запрос на слияние:
после создания осуществляется переход на страницу запроса
Запрос можно редактировать, нажав кнопку .
Важно, что после создания «Merge request», можно отправлять новые коммиты в ветку «new_branch» репозитория Gitlab — эти коммиты будут попадать в созданный запрос на слияние «Merge request» и будут применены при слиянии веток после одобрения:
07 Одобрение и слияние веток:
Хозяину ветки «develop» остается проверить коммиты, «Одобрить» и принять через «Слияние» наши изменения из «new_branch»:
При возникновении конфликтов при слиянии веток, хозяину «develop» нужно их разрешить самостоятельно или отправить инициатору изменений «new_branch» для разрешения конфликтов на его стороне.