How can I get the URL to a merge request or a pull request of my current branch using git?
I would like to obtain the link to the associated PR/MR of the current branch using Git CLI .
2 Answers 2
You mean https link ?
I don’t know the way to get the link you want,
but you can get that kind of link by webhook of GitLab after the PR/MR event.
Git is unaware of pull (GitHub) or merge (GitLab) requests. This means that the Git CLI is unable to do what you want.
Git is, however, a set of tools, not a specific solution. You can simply add your own tools. The Unix-style of working is to treat everything as a tool, to whatever extent possible, so if you’re using bash or zsh, you can add non-Git tools as well.
GitHub, for instance, provide a CLI tool of their own called gh. There is a StackOverflow tag for gh-related questions: github-cli. There are also GitLab tools, e.g., this one and this one, although there don’t seem to be StackOverflow tags for these.
You’ll find one big stumbling block here, and that is the fact that branches, in Git—regardless of which of several common meanings you intend by the word branch—are slippery and have little real substance. There may be a branch named feature/tall in repository X on GitHub, which you use in your own clone under the entirely different name feature/short . Is this branch "tall" or "short"? The answer is either "yes" or "both".
The simple solution to this stumbling block is "don’t do that": if you keep your names such that they match up with some other repository’s names, you won’t ever hit this problem. The fault with this simple solution occurs when there are multiple "other repositories" in question and they:
- use different names, and/or
- use the same names, but for different commits
which results in you being unable to use a single name to match. But this is rare, so you may be able to ignore it.
Creating a pull request
Create a pull request to propose and collaborate on changes to a repository. These changes are proposed in a branch, which ensures that the default branch only contains finished and approved work.
Anyone with read access to a repository can create a pull request.
If you want to create a new branch for your pull request and do not have write permissions to the repository, you can fork the repository first. For more information, see «Creating a pull request from a fork» and «About forks.»
You can specify which branch you’d like to merge your changes into when you create your pull request. Pull requests can only be opened between two branches that are different.
Note: To open a pull request in a public repository, you must have write access to the head or the source branch or, for organization-owned repositories, you must be a member of the organization that owns the repository to open a pull request.
You can link a pull request to an issue to show that a fix is in progress and to automatically close the issue when someone merges the pull request. For more information, see «Linking a pull request to an issue.»
Changing the branch range and destination repository
By default, pull requests are based on the parent repository’s default branch. For more information, see «About branches.»
If the default parent repository isn’t correct, you can change both the parent repository and the branch with the drop-down lists. You can also swap your head and base branches with the drop-down lists to establish diffs between reference points. References here must be branch names in your GitHub repository.
When thinking about branches, remember that the base branch is where changes should be applied, the head branch contains what you would like to be applied.
When you change the base repository, you also change notifications for the pull request. Everyone that can push to the base repository will receive an email notification and see the new pull request in their dashboard the next time they sign in.
When you change any of the information in the branch range, the Commit and Files changed preview areas will update to show your new range.
Tips:
- Using the compare view, you can set up comparisons across any timeframe. For more information, see «Comparing commits.»
- Project maintainers can add a pull request template for a repository. Templates include prompts for information in the body of a pull request. For more information, see «About issue and pull request templates.»
Creating the pull request
- On GitHub.com, navigate to the main page of the repository.
- In the «Branch» menu, choose the branch that contains your commits.
Pull request.
Tip: After you create a pull request, you can ask a specific person to review your proposed changes. For more information, see «Requesting a pull request review.»
After your pull request has been reviewed, it can be merged into the repository.
To learn more about GitHub CLI, see «About GitHub CLI.»
To create a pull request, use the gh pr create subcommand.
To assign a pull request to an individual, use the —assignee or -a flags. You can use @me to self-assign the pull request.
To specify the branch into which you want the pull request merged, use the —base or -B flags. To specify the branch that contains commits for your pull request, use the —head or -H flags.
To include a title and body for the new pull request, use the —title and —body flags.
To mark a pull request as a draft, use the —draft flag.
To add a labels or milestones to the new pull request, use the —label and —milestone flags.
To add the new pull request to a specific project, use the —project flag.
To assign an individual or team as reviewers, use the —reviewer flag.
To create the pull request in your default web browser, use the —web flag.
- Click Preview Pull Request. GitHub Desktop will open a preview dialog showing the diff of the changes between your current branch and the base branch.
Alternatively, to go straight to GitHub to create your pull request, select the dropdown icon and click Create Pull Request.
Confirm that the branch in the base: dropdown menu is the branch where you want to merge your changes.
GitHub Desktop will advise you whether the current branch can be automatically merged into the base branch.
Click Create Pull Request. GitHub Desktop will open your default browser to take you to GitHub.
Type a title and description for your pull request.
To create a pull request that is ready for review, click Create Pull Request. To create a draft pull request, use the drop-down and select Create Draft Pull Request, then click Draft Pull Request. For more information about draft pull requests, see «About pull requests.»
- Once you’ve committed changes to your local copy of the repository, click the Create Pull Request icon.
For more information on creating pull requests in GitHub Codespaces, see «Using GitHub Codespaces for pull requests.»
- «Creating a pull request from a fork»
- «Keeping your pull request in sync with the base branch»
- «Changing the base branch of a pull request»
- «Adding issues and pull requests to a project (classic)»
- «Creating an issue»
- «Assigning issues and pull requests to other GitHub users»
- «Writing on GitHub»
Help us make these docs great!
All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.
Создание pull-запроса на GitHub
Распределённая система контроля версий Git обеспечивает простоту поддержки и разработки открытого программного обеспечения, в создании которого участвует команда специалистов. Сама система Git является ярким примером проекта с открытым исходным кодом. Множество проектов хранят файлы в репозиториях Git, а такие сайты как GitHub позволяют быстро внести свой вклад в развитие того или иного проекта.
Проекты с открытым исходным кодом, размещённые в публичных репозиториях, развиваются за счет вклада широкого сообщества разработчиков с помощью. Проект принимает внесённые в код изменения с помощью pull-запросов.
Данное руководство научит вас делать pull-запросы в репозитории Git с помощью командной строки.
Требования
- Предварительно установленная система контроля версий Git. Подробные инструкции по установке можно найти здесь.
- Аккаунт GitHub. Регистрация бесплатная. Чтобы зарегистрироваться, укажите имя пользователя и адрес электронной почты.
- Проект, в разработке которого вы хотите участвовать. Больше информации об открытых проектах можно найти здесь.
Создание копии репозитория
Репозиторий – это главная папка проекта. Репозиторий содержит все файлы проекта, включая документацию и хронологию изменений для каждого файла. Репозитории на GitHub могут иметь несколько соавторов, также они могут быть публичными и приватными.
Чтобы начать работу над открытым проектом, нужно сначала создать собственную копию репозитория. Чтобы получить локальную рабочую копию кода, создайте форк проекта (ветвление, fork) и клонируйте его.
Форк проекта
Чтобы создать форк репозитория GitHub, откройте сайт GitHub и найдите открытый проект, в разработке которого вы хотите участвовать. Ссылки GitHub содержат имя владельца проекта и название самого проекта.
К примеру, репозиторий проекта node-chakracore принадлежит nodejs, значит, ссылка GitHub будет выглядеть так:
где nodejs – имя пользователя, node-chakracore – имя репозитория.
Выберите проект, в котором вы хотите принять участие, и откройте его репозиторий на GitHub.
На главной странице проекта вы увидите кнопку Fork под вашим значком пользователя.
Чтобы начать форк репозитория, нажмите кнопку Fork. В окне браузера появится следующее сообщение:
Forking nodejs/node-chakracore
It should only take a few seconds.
Когда процесс будет выполнен, в браузере вы увидите такой же репозиторий, как и раньше, но в ссылке уже будет указано ваше имя.
Теперь можно клонировать репозиторий и получить локальную копию кода.
Клонирование репозитория
Чтобы создать локальную копию кода проекта, откройте терминальное окно. Используйте команду git clone и укажите ссылку на форк репозитория.
Эта ссылка почти такая же, как и предыдущая, и отличается только тем, что заканчивается расширением .git, например:
Скопировать эту ссылку можно с помощью зелёной кнопки Clone or download на странице репозитория. Справа от ссылки появится кнопка, с помощью которой можно скопировать ссылку.
Теперь можно добавить скопированный URL в команду git clone:
git clone https://github.com/your-username/repository.git
Создание новой ветки
Работая над открытым проектом, разработчики предлагают внедрить в основной код различные новые функции и исправления. Некоторые идеи можно реализовать в короткие сроки, в то же время на реализацию других идей может уйти много времени и ресурсов. Поэтому разработчики создают ветку репозитория: это позволяет управлять рабочим процессом, изолировать изменения друг от друга и выбирать функции, которые нужно добавить в основную ветку репозитория проекта.
По умолчанию главная ветка репозитория называется master. Код, который находится в главной ветке, может развернуть любой пользователь.
Создавая новую ветку из ветки master, важно выбрать описательное имя: например, вместо my-branch лучше использовать frontend-hook-migration или fix-documentation-typos.
Чтобы создать ветку, откройте окно терминала и перейдите в репозиторий:
Примечание: Замените repository названием своего репозитория.
Затем используйте команду git branch:
git branch new-branch
Примечание: Вместо new-branch укажите описательное имя ветки.
Чтобы перейти на новую ветку, используйте команду:
git checkout new-branch
Switched to branch ‘new-branch’
С помощью флага -b можно объединить две предыдущие команды в одну, которая создаст новую ветку и переключится на неё:
git checkout -b new-branch
Чтобы вернуться на ветку master, используйте команду checkout и укажите имя ветки:
git checkout master
С помощью этой команды можно переключаться между различными ветками.
Теперь можно приступать к созданию новых и редактированию существующих файлов.
Локальные изменения кода
Внеся изменения в код, вы можете добавить их в локальный реопзиторий с помощью команды git add. Чтобы добавить все изменения в репозиторий, используйте флаг –A.
Чтобы записать изменения, добавленные в репозиторий, используйте команду git commit.
Создание сообщения коммита – очень важный этап работы над открытым проектом. Это сообщение позволяет другим разработчикам понять, что именно вы изменили в коде и почему это изменение важно. Кроме того, сообщения коммитов предоставляют хронологическую запись изменений проекта в целом, помогая новым разработчикам понять, как развивался проект.
Короткое сообщение коммита можно отправить с помощью флага –m, например:
git commit -m «Fixed documentation typos»
Но если вы внесли существенные изменения в код проекта, вы должны написать более подробное сообщение. Для этого введите:
Команда откроет текстовый редактор. Если вы хотите выбрать текстовый редактор для создания коммита, добавьте название редактора в команду:
git config —global core.editor «nano»
или
git config —global core.editor «vim»
После запуска команды git commit на экране появится документ в текстовом редакторе, который выглядит примерно так:
# Please enter the commit message for your changes. Lines starting
# with ‘#’ will be ignored, and an empty message aborts the commit.
# On branch new-branch
# Your branch is up-to-date with ‘origin/new-branch’.
#
# Changes to be committed:
# modified: new-feature.py
#
Под комментариями вы можете добавить сообщение коммита.
Чтобы сообщение коммита было полезным для других разработчиков, поместите в начале сообщения краткое описание изменений длиной около 50 символов. Далее добавьте несколько разделов:
- раскройте причину, по которой вы внесли это изменение в код;
- опишите, как работает код;
- предоставьте дополнительную информацию, которая может пригодиться другим разработчикам.
Постарайтесь предоставить в сообщении максимум полезной информации.
Сохраните и закройте текстовый файл с коммитом. После этого можно проверить его состояние:
Команда должна вернуть примерно такой вывод:
On branch new-branch
Your branch is ahead of ‘origin/new-branch’ by 1 commit.
(use «git push» to publish your local commits)
nothing to commit, working directory clean
Теперь можно использовать команду git push, чтобы выгрузить изменения в текущую ветку форка репозитория:
git push —set-upstream origin new-branch
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 336 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/your-username /respository .git
a1f29a6..79c0e80 new-branch -> new-branch
Branch new-branch set up to track remote branch new-branch from origin.
Теперь можно открыть форк репозитория на странице GitHub, переключиться на ветку, в которую вы внесли изменения, и просмотреть её.
На данном этапе вы уже можете сделать pull-запрос к оригинальному репозиторию. Но сначала рекомендуется обновить локальный репозиторий.
Обновление локального репозитория
Работая над открытым проектом вместе с другими разработчиками, важно постоянно следить за обновлениями и своевременно обновлять свой локальный репозиторий. В противном случае при создании pull-запроса может возникнуть конфликт.
Настройте удалённый репозиторий и синхронизируйте его с оригинальным репозиторием.
Настройка удалённого репозитория
Удалённый репозиторий – это размещённая в интернете версия проекта, к которой у вас есть доступ. Каждый удаленный репозиторий должен предоставлять вам право на чтение (или чтение и запись).
Чтобы синхронизировать изменения, внесенные в форк, с оригинальным репозиторием, вам нужно настроить удалённый репозиторий, который будет ссылаться на оригинальный репозиторий.
Сначала проверьте, какие удалённые серверы у вас настроены. Команда git remote с флагом –v отобразит URL-адреса, которые Git хранит вместе с соответствующими краткими именами удалённых серверов. Сейчас у вас есть только один репозиторий, origin.
Поскольку вы клонировали репозиторий, вывод будет примерно таким:
origin https://github.com/your-username/forked-repository.git (fetch)
origin https://github.com/your-username/forked-repository.git (push)
Если же ранее вы создали более одного удалённого репозитория, команда git remote –v выведет на экран полный список этих репозиториев.
Теперь нужно создать репозиторий upstream, который указывает на оригинальный репозиторий.
git remote add upstream https://github.com/original-owner-username/original-repository.git
В данном примере upstream – это короткое имя удаленного хранилища, так как с точки зрения Git «upstream» ссылается на репозиторий, из которого вы клонировали свой репозиторий. Чтобы добавить удалённый репозторий со ссылкой на репозиторий соавтора, можно указать имя соавтора или его ник.
Чтобы убедиться, что удалённый репозиторий upstream был успешно добавлен, в каталоге репозитория запустите команду:
git remote -v
origin https://github.com/your-username/forked-repository.git (fetch)
origin https://github.com/your-username/forked-repository.git (push)
upstream https://github.com/original-owner-username/original-repository.git (fetch)
upstream https://github.com/original-owner-username/original-repository.git (push)
Теперь вы можете синхронизировать форк с исходным репозиторием.
Синхронизация форка
В терминале перейдите в каталог локального репозитория и используйте команду git fetch, чтобы извлечь все ветки и их коммиты из оригинального репозитория.
git fetch upstream
Вывод команды зависит от того, сколько изменений появилось в исходном репозитории. В конце вывода содержатся примерно такие строки (они варьируются в зависимости от того, сколько веток входит в проект):
From https://github.com/original-owner-username/original-repository
* [new branch] master -> upstream/master
Теперь коммиты ветки master будут храниться в локальной ветке upstream/master.
Перейдите на локальную ветку master:
git checkout master
Switched to branch ‘master’
Теперь можно объединить все изменения, которые были сделаны в ветке master исходного репозитория, с локальной веткой.
git merge upstream/master
Вывод начинается с Updating, если в ветке появились новые данные. Если никаких изменений не произошло, команда вернёт Already up-to-date.
Ветка master вашего форка теперь синхронизирована с репозиторием upstream.
В зависимости от вашего рабочего процесса и количества времени, которое вы тратите на внесение изменений, вы можете синхронизировать ваш форк с кодом исходного репозитория столько раз, сколько вам нужно. Но вы обязательно должны синхронизировать форк, прежде чем сделать pull-запрос, чтобы ваш код не конфликтовал с остальным кодом проекта.
Создание pull-запроса
Теперь вы можете сделать pull-запрос к исходному репозиторию.
Перейдите в форк репозитория в браузере и нажмите кнопку New pull request слева.
На следующем экране вы можете отредактировать ветку и выбрать репозиторий в выпадающем меню.
После этого на экране появится форма, в которой вы можете добавить заголовок, оставить комментарий и т.п.
GitHub сообщит вам, если вы можете объединить две ветки. Добавьте заголовок, комментарий и нажмите Create pull request.
Пользователи, поддерживающие исходный репозиторий, рассмотрят ваш запрос. Возможно, они предложат вам внести в него некоторые изменения.
Заключение
Теперь вы умеете отправлять pull-запросы, работая над открытыми проектами.
Разработка проекта с открытым исходным кодом может стать полезным опытом.
Pull request’ы на GitHub или Как мне внести изменения в чужой проект
По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub’а Fork A Repo и Send pull requests.
Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:
Немного о моделях совместной разработки
- Модель «Fork + Pull» позволяет любому склонировать (fork) существующий репозиторий и сливать изменения в свой личный fork без необходимости иметь доступ к оригинальному репозиторию. Затем, изменения должны быть включены в исходный репозиторий его хозяином. Эта модель уменьшает количество телодвижений для новых contributors и популярна для open source проектов, так как позволяет людям работать независимо, без единого координирования.
- Модель «общего репозитория» (The Shared Repository Model) чаще встречается у малых команд и организаций, работающих над закрытыми проектами. Каждый в команде имеет доступ «на запись» в один общий репозиторий, а для изолирования изменений применяются тематические ветви (topic branches).
Делаем копию репозитория
Рассматривая первую модель разработки, необходимо иметь свою копию изначального репозитория, в которой и будет вестись работа, и изменения из которой и будут предлагаться затем автору изначального репозитория.
В рамках руководства, будем считать, что мы работаем над репозиторием Spoon-Knife пользователя octocat, а ваше имя пользователя — username.
Сделать это очень просто: на странице репозитория имеется кнопочка «Fork», которую и следует нажать. 
После чего, эту свою копию уже можно «стянуть» на свой компьютер:
Склонированный репозиторий имеет одну привязку к удалённому репозиторию, названную origin, которая указывает на вашу копию на GitHub, а не на оригинальный репозиторий, чтобы отслеживать изменения и в нём, вам нужно будет добавить другую привязку, названную, например, upstream.
Делаем работу
Итак, в этой точке мы уже можем править код и делать коммиты. Если вы сделали все предыдущие шаги, чтобы потом вернуть ваши изменения в оригинальный репозиторий, то я настоятельно советую делать всю работу в отдельной тематической ветви разработки. Полезность этого станет ясна на этапе посылки pull request’а. Пускай она будет называться feature.
Вот, теперь творите добро (и пусть оно будет выражаться в коммитах).
Как только вы сделали работу (или её часть), отправьте её в свою копию репозитория на GitHub:
Возвращаем изменения: Pull request
Итак, всё сделано. Вы написали код, он у вас в ветви feature как у вас на компьютере, так и на GitHub’е. Осталось только «заслать» его в оригинальный репозиторий.
Идите на страницу вашей копии репозитория на GitHub, выбирайте ветвь feature и жмите кнопку Pull Request. 
Далее вы попадёте на предпросмотровую страницу, на которой сможете ввести название и описание ваших изменений (название потом попадёт в описание мёрдж-коммита и станет достоянием общественности, учтите это). 
Там же вы можете посмотреть, какие коммиты попали в пулл реквест: 
А так же общий diff всех изменений в пулл реквесте: 
По умолчанию, пулл реквесты считаются основанными на самой часто интегрируемой ветви родительского репозитория. В этом случае username/Spoon-Knife был скопирован с octocat/Spoon-Knife, так что pull request считается основанным на ветке master репозитория octocat/Spoon-Knife. В большинстве случаев, это будет корректно, но если не так, то вы можете нажать на кнопку «Change Commits»
Вы попадёте в форму выбора базовой и исходной ветвей: 
Слева выбираете в какую ветку будут вливаться изменения в родительском репозитории, справа — какие изменения будут браться с вашего репозитория. По примеру: справа octocat/Spoon-Knife/master, слева username/Spoon-Knife/feature. Здесь вы можете указывать не только ветки, но так же теги и id отдельных коммитов в соответствующем репозитории.
ВАЖНО: Договоритесь с владельцем «родительского» репозитория, в какую ветку будете вливать изменения (он может написать это в README)
Изменение базового репозитория меняет и список людей, кто получит уведомление о пулл реквесте. Каждый, кто имеет право «на запись» в базовый репозиторий, получит письмо и увидит уведомление на главной GitHub’а, в следующий раз, как на него зайдёт.
Как только список коммитов вас удовлетворит, нажмите кнопку Update Commit Range.
Когда вы ввели название и описание и перепроверили список коммитов и изменения в файлы, попавшие в пулл реквест, нажмите кнопку Send pull request. Пулл реквест будет создан незамедлительно.
Что дальше?
Следите за вашим пулл-реквестом. Что прокомментируют люди, что скажет мэйнтэйнер, примет или нет ваш пулл реквест.
Помните, я говорил, что следует все изменения, которые пойдут в пулл, держать в отдельной ветке? Так вот, основное удобство: вы всегда можете добавить коммиты к уже существующему пулл реквесту, просто добавив их к этой ветке в вашем репозитории (да-да, просто git push origin feature , при условии, что вы указали в пулл реквесте feature как исходную ветвь)
- Комментарии, оставленные к пулл реквесту;
- Дополнительные коммиты, добавленные к ветви пулл реквеста;
- Комментарии к изменённым строкам или файлам, оставленные к любому из коммитов, включенных в пулл реквест.
Когда ваш pull request примут, не забудьте слить изменения в свой репозиторий (или удалить его, если больше не нужен):
Так же можно удалить ветку, в которой велась разработка:
Что следует делать, если работа заняла большое время и оригинальный репозиторий успел уйти вперёд?
Можно просто влить изменения из оригинального репозитория к себе:
Однако хозяину оригинального репозитория или, может быть, даже вам, не понравится наличие мёрж-коммитов и коммитов из master’а в списке коммитов на пулл. В таком случае вам стоит воспользоваться git rebase.
Прочитать про то, как работает rebase можно в официальном руководстве. Там имеются и очень понятные иллюстрации. Так же есть статья в помощи GitHub.
ВНИМАНИЕ: Пожалуйста, учтите, что git rebase меняет id коммитов! Поэтому, все действия с этой командой стоит выполнять только на локальном репозитории, до того, как эти коммиты станут общедоступны, т.е. до того, как вы их push’нули на гитхаб.
Если вы хозяин: Как принять pull request
Если пулл реквест удовлетворяет всем условиям, то кто-либо с правом «на запись» (т.е. может сделать push) в целевой репозиторий, должен принять pull request одним из многих методов. Ниже описаны три наиболее популярных метода:
Auto Merge (автослияние)
Во многих случаях можно попросить github автоматически принять пулл реквест, используя большую зелёную кнопку Merge Pull Request, которая сама вольёт изменения, создаст мёрж-коммит и закроет пулл реквест. 
Подробнее можно почитать в этом хабратопике: Кнопка слияния на GitHub.
Fetch and Merge (скачать и слить)
Основной метод вливания изменений. Он требует добавления remote, ведущего к репозиторию человека, отправившего pull request, скачивания изменений с этого репозитория, объединения нужной ветви, исправления конфликтов и выгрузки обновлённой ветви обратно в исходный репозиторий:
Patch and Apply (пропатчить и принять)
Предыдущий метод работает хорошо, когда вы работаете в команде или постоянно принимаете изменения от одной и той же группы людей. Другой метод немного быстрее в единичных случаях при использовании git-am.
У каждого пулл реквеста есть свой .patch URL, с которого можно скачать текстовый патч, чтобы скормить его команде git-am:
Закрытие пулл реквеста
Запросы на пулл автоматически закрываются, когда запрошенные коммиты вливаются в репозиторий назначения. При этом генерируется событие, информирующее всех участников разработки, что пулл реквест был принят и влит в основную ветвь. 
Так же возможно вручную закрыть пулл реквест в случае, если он был отклонён. Иногда это необходимо в случаях, когда изменения были приняты с помощью git-cherry-pick или другого механизма, который не позволяет обнаружить факт слияния (merge).