Pull request

Расскажу, как быстро и просто открыть пулл-реквест, на что обратить внимание, и сделать так, чтобы ваш ревьюер не расстраивался. В конце статьи есть чеклист, чтобы быстро проверять по нему.

Предполагаю, что вы уже форкнули проект, склонировали себе форк, что-то там накоммитили и готовы открыть пулл-реквест. Лучше всего читать эту статью параллельно с открыванием пулл-реквеста.

Найдите кнопку «Pull Request»

Не суетитесь и не бегайте по репозиториям, переключая ветки. Сразу, как вы запушили, на главной страничке вашего репозитория появится жёлтая плашка с названием ветки и кнопкой «Compare & pull request».

Эта кнопка — самый короткий путь к открытию пулл-реквеста. Жмите её.

Проверьте ветки

После нажатия кнопки у вас откроется подробная страничка о том, откуда и куда вы открываете пулл-реквест. Посмотрите, куда вольётся ваш код. Он должен попадать в главную ветку основного репозитория. Скорее всего это ветка master. И он должен быть из вашего форка и ветки, в которой вы делали работу.

Скорее всего так и есть, если вы правильную кнопку нажали.

Проверьте конфликты

Прямо под ветками написано, есть конфликты или нет:

Бывает, что конфликты есть:

Хорошим тоном считается открывать пулл-реквесты без конфликтов.

Поэтому если у вас конфликт, решите его до того, как откроете пулл-реквест. Можно отребейзить вашу ветку от мастера главного репозитория, или можно влить мастер главного репозитория в вашу ветку.

Если вы работаете в команде и не умеете решать конфликты, попросите старшего товарища вам помочь. А если вы студент, попросите наставника 🙂 Вы так же можете сначала открыть пулл-реквест, пусть и с конфликтами, а потом эти конфликты решить.

Напишите заголовок и описание

В форме открытия пулл-реквеста напишите заголовок: коротко что вы сделали. И описание: что конкретно и зачем, а что ещё не доделано.

Проверьте изменённые файлы

Ниже формы с описанием пулл-реквеста есть дифф — это то, что изменилось: новые файлы, удалённые файлы, изменённые строки в файлах.

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

На скриншоте выше файл очевидно лишний. Значит нужно его удалить и закоммитить это, и снова запушить в эту ветку. Если вы нашли ошибку, то просто исправьте её, закоммитьте и запушьте. Потом обновите страничку с диффом и убедитесь, что всё в порядке.

Теперь жмите «Create pull request»! Ура!


Как открыть пулл-реквест:

  1. После пуша зайдите в свой репозиторий и нажмите кнопку «Compare & pull request» на жёлтой плашке.
  2. Проверьте, что открываете пулл-реквест из своей ветки в мастер главного репозитория.
  3. Проверьте, нет ли конфликтов. Если есть, исправьте их.
  4. Напишите заголовок и описание.
  5. Проверьте, что в диффе нет ничего лишнего. Если что-то лишнее попало, уберите это.
  6. Откройте пулл-реквест 🙂

Create a pull request

  • Время чтения: 4 мин

VSTS | TFS 2018 | TFS 2017 | TFS 2015 | VS 2017 | VS 2015

Git's workflow uses branches to isolate work until you're ready to merge the changes into your default branch, such as . The pull request is the collaborative process that lets the rest of the team discuss changes in a branch and agree to merge them once everyone approves. Use pull requests to get early feedback from others on work in progress, even if you're not ready to merge the changes into another branch.

In this image, the purple branch is merged into the blue branch through a pull request. The changes are discussed by reviewers in the pull request before the code is merged. When you complete the pull request, there is a merge commit (seen here as the filled blue commit) where the changes in the purple branch are now merged in the blue branch.

In this tutorial you learn how to:

  • Create a pull request
  • Complete a pull request

Create a pull request

To create a pull request in VSTS:

  1. Push your local branch.
  2. Create a pull request for the branch in VSTS. You can do this in the Code view on the web from either the Pull Requests tab or the Files tab.

    You can also initiate a pull request from Visual Studio. Select the Pull Requests view when connected to your Team Project.

    From the Pull Requests view you can view pull requests opened by you, assigned to you, and you can create new pull requests. Select New Pull Request to open up a web browser where you can create the new pull request in the VSTS web portal for your current branch.

  3. Create the pull request. You should give a clear title for the pull request that describes the changes in the branch. In the description field give a clear explanation of how the changes are implemented along with any resources that might help reviewers understand the changes. You can include VSTS work items and hyperlinks to allow others to have as much context as possible when reviewing your changes. Add any team member who you would like to review the changes.

Who reviews the pull request?

When you create the pull request, you can add others who need to review your changes. You can add users and groups to the pull request after it is created if the scope of the review needs to expand. You can also associate the pull request with a task in VSTS to let others working with the task know changes are ready for review.

How does the code review work?

Pull request reviewers will see the proposed updates to the branch in the form of file differences between the two branches. Reviewers can add comments on any of the changes and include notifications for other team members to answer a question or give other feedback. You can make changes and push commits to resolve issues brought up in the feedback and these changes are immediately reflected in the pull request.

If the changes need much more development to complete, you can abandon the pull request. You can later open up a new pull request to revisit the changes and link to the conversations that took place in the abandoned pull request.

You can also open up a pull request on a very early version of your code to ask for feedback from others, even if the code isn't ready to merge yet. Once you get the team's feedback, you can keep the pull request open to continue the conversation or abandon the pull request until your code is ready to be shared again.

Complete a pull request

Complete your pull request after the reviewers approve of the changes by selecting Complete in the upper right of the pull request view.

  • Complete: Complete the pull request now and merge the changes to the target branch.
  • Set auto-complete: If you have branch policies, you can choose Set auto-complete to configure the pull request to close once all branch policies are met. Fore more information on auto-complete (and reasons why you might not see this option), see Complete automatically.
  • Abandon: Choose Abandon to close the pull request without merging the changes.

Enter the message used for the merge commit and update the pull request description as needed in the dialog that follows.

  • Check Complete linked work items after merging to complete any linked work items.
  • Check Delete after merging to delete the source branch from the pull request. Git retains the commit history in the branch after the pull request is complete, so unless you plan on doing more work in the branch, it is safe to remove.
  • Check Squash changes when merging to squash merge your pull request.
  • Check Override branch policies and enable merge to force merge even if all branch policies haven't been satisfied. This option is only available if you have Exempt from policy enforcement permissions.

What happens when a pull request is merged?

You must resolve any merge conflicts between the pull request branch and the target branch. Git adds a new commit (the merge commit) to the end of the master branch. This merge commit links the earlier history of both the master branch and the commits for the branch that was merged as part of the pull request.

Next steps

30. Разрешение конфликтов

Цели

  • Научиться разрешать конфликты во время слияния

01 Слияние master с веткой style

Теперь вернемся к ветке style и попытаемся объединить ее с новой веткой master.

Выполните:

git checkout style git merge master

Результат:

$ git checkout style Switched to branch ‘style’ $ git merge master Auto-merging lib/hello.html CONFLICT (content): Merge conflict in lib/hello.html Automatic merge failed; fix conflicts and then commit the result.

Если вы откроете lib/hello.html, вы увидите:

Файл: lib/hello.html

<!— Author: Alexander Shvets (alex@githowto.com) —> <html> <head> <<<<<<< HEAD <link type=»text/css» rel=»stylesheet» media=»all» href=»style.css» /> ======= <!— no style —> >>>>>>> master </head> <body> <h1>Hello,World! Life is great!</h1> </body> </html>

Первый раздел — версия во главе текущей ветки (style). Второй раздел — версия ветки master.

02 Решение конфликта

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

Файл: lib/hello.html

<!— Author: Alexander Shvets (alex@githowto.com) —> <html> <head> <link type=»text/css» rel=»stylesheet» media=»all» href=»style.css» /> </head> <body> <h1>Hello, World! Life is great!</h1> </body> </html>

03 Сделайте коммит решения конфликта

Выполните:

git add lib/hello.html git commit -m «Merged master fixed conflict.»

Результат:

$ git add lib/hello.html $ git commit -m «Merged master fixed conflict.» Recorded resolution for ‘lib/hello.html’. [style 645c4e6] Merged master fixed conflict.

04 Расширенные возможности слияния

Git не предоставляет никаких графических инструментов слияния, но будет с удовольствием работать с любыми сторонними инструментами слияния, которые вы хотите использовать (обсуждение таких инструментов на StackOverflow).

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

Закрыть меню