Pull Request vs. Merge Request
When it comes to choosing a Git management tool, you need to consider various factors as it significantly affects the workflow. One of the most important aspects is how collaboration is organized in this application. Pull Request in Bitbucket and GitHub or Merge Request in GitLab are the features made for more convenient code review. These features are equivalent as they both do the same git merge command to merge feature branches or forks with the existing code.
You probably want to ask why you need to use a special tool for something that a git command can do, but convenience and efficiency are what makes a difference here:
Working with Pull Requests in Bitbucket
Let’s look at how to use pull requests in Bitbucket and what information about your team performance you can get from it.
For instance, one of your developers has just finished working on a feature in a dedicated branch. Now, this feature should be merged with the development branch. But first, other team members should review it.
So, your developer navigates to Create pull request, chooses the feature branch as Source and the development branch as Destination. The developer can add the Title and Description of the pull request and choose who will be Reviewers of it or leave it without a particular reviewer.
Then a discussion of the feature begins. Each reviewer can:
Working with Merge Requests in GitLab
Now let’s find out how to use the Merge Request feature in GitLab to improve the code review process.
Navigate to Merge Requests and click New merge request.
Choose the Source branch that you want to merge and the Target branch which will be the destination.
Same as Bitbucket, GitLab allows you to choose who will review this request. It’s also possible to see the changes in edited files, the commits included in the merge request, discuss the feature, and make suggestions.
When reviewers approve the changes, click Merge to merge branches.
Insights on Your Team Performance in Bitbucket
While working in Bitbucket, you can also evaluate your team performance using the Awesome Graphs for Bitbucket app. It is possible to:
Improve your development process
Such collaboration while working on the project positively affects the quality of the code your team produces. Moreover, pull requests definitely reduce the number of bugs in the code.
As a result, the quality of your product gets better, and your customers become much more satisfied. Thanks to the detailed analysis of your team’s performance using Awesome Graphs for Bitbucket app, it’s possible to improve it and increase the speed of the development process.
Что такое pull request?
Что такое «пул реквест» (pull request), который на GitHub, и как его применить?
4 ответа 4
К вышесказанному можно добавить следующее. Далеко не все пулл-реквесты принимаются разработчиками. Тут нужно соблюсти ряд правил:
Пулл-реквест (ПР) должен быть хорошо оформлен и содержать исчерпывающее описание.
Очень важно соблюдать Code Style того проекта, для которого вы делаете ПР. Пусть даже он кажется вам противоестественным (например вы всегда делаете отступы в виде 4 пробелов, а в проекте табы).
Не нужно бояться делать ПР-ы, ведь помочь можно даже в мелочи. Например вы заметили ошибку перевода в readme файле или вам кажется что какое-то описание фичи можно более понятно перефразировать.
На гитхабе миллионы проектов, живущие исключительно на энтузиазме создателей, хорошие ПР-ы очень хорошо подстегивают этот энтузиазм)
еще добавки к вышесказанному: возможный (я им пользуюсь) механизм работы с репами/pr:
git clone https://github.com/ваш_юзернейм/sqlpp11.git
git remote add upstream https://github.com/rbock/sqlpp11.git (т.е. мы добавляем псевдоним upstream для оригинального репозитория, мы не можем добавлять в него изменения, но можем их получать)
теперь вы правите файлы в вашем origin, в вашей ветке, пушите их в свой форк гитхаба (origin), откуда и делаете pull-request
при этом вы можете сделать git merge/pull/fetch upstream с оригинального репозитория (upstream)
если в upstream настроена интеграция типа travis-ci (как в моем примере), лучше не делать пулл-реквесты, пока не настроите travis-ci для своего репозитория и ваши билды не будут работать правильно (чтобы не мучать мэйнтейнера upstream бессмысленными сообщениями о неудачных сборках в пулл-реквесте)
1. Что такое pull request?
1. Определение
pull request — предложение изменения кода в чужом репозитории.
Вы делаете форк чужого репозитория (который иногда и сам может быть форком) → производите изменения в своём форке → посредством pull request предлагаете изменения владельцам репозитория, чей форк Вы сделали. На GitHub pull request в публичный репозиторий может осуществить любая/ой зарегистрированная/ый участница/участник.
2. Составляющие pull requests
Рекомендации по грамотному внесению pull requests расписаны в ответе ув-мого IonDen.
3. Разновидности pull requests
Все pull requests можно разделить на следующие категории:
4. Дополнительная ссылка
2. Как сделать и принять pull request при помощи hub
1. Что такое hub?
hub — консольное приложение, упрощающее введение команд git, обёртка для git. Например, чтобы клонировать репозиторий, используя git, мы должны ввести в терминал:
В hub команда выглядит проще:
Полный список команд hub, и что они упрощают, см. в документации hub.
2. Зачем использовать hub?
Фиксить мелкие баги и опечатки, а затем сделать pull-request проще через веб-интерфейс GitHub. Однако если Ваши изменения довольно значительны, лучше клонировать репозиторий к себе на компьютер по следующим причинам:
Итак, вы решили клонировать репозиторий. hub упрощает:
3. Настройка hub перед использованием
Если путь к исполняемому файлу содержит пробелы, во избежание багов, лучше заключить его в кавычки.
При необходимости резервных копий или синхронизации пользовательской конфигурации файлов git узнать, где хранятся конфигурационные файлы git, начиная с версии 2.8 можно командой:
Например, у меня в Windows 10 путь к файлу, где хранится данная настройка для комментариев, оказался следующим:
Если Ваша проблема отлична от расписанных здесь, и её разрешения не получается найти поисками Google и по репозиторию; попробуйте ещё раз воспроизвести проблему, перед введением команд hub послав в терминал следующую команду:
В терминале появится отладочная информация. Если и по ней не получилось разрешить проблему, создайте багрепорт в issue tracker hub, приложив к сообщению вывод Вашего терминала вместе с отладочной информацией.
4. Пример создания pull request через hub
Сделаем посредством PowerShell и hub pull request в репозиторий https://github.com/LightAlf/bioRepo1. Помимо вышеперечисленных команд hub в примере используются также команды git, о предназначении которых можно узнать, например, из данного или этого ресурсов на русском.
5. Пример принятия pull-request при помощи hub
В описании коммита по умолчанию будут ссылки на коммит, которым приниматеся pull request, и на сам pull request, а также его заголовок.
Пользовательница/пользователь GitHub, у которой/которого Вы приняли pull request, не сразу, но будет указана/указан в числе контрибьюторов Вашего репозитория.
Что такое пул-реквесты и зачем они нужны?
Перевод статьи «What’s the Point of Pull Requests Anyway?»
Если вы еще новичок в мире Git и тесно связанных с ним платформ (например, GitHub или GitLab), то вы могли и не слышать таких терминов, как пул-реквест (pull request) или мерж-реквест (merge request). И даже если что-то такое слышали, то можете не знать, что означают эти термины и зачем нужны эти самые «реквесты».
Примечание. В статье я буду использовать термин «пул-реквест», но по сути это то же самое, что мерж-реквест, только последний используется на GitLab.
Пул-реквесты помогают командам создавать программы и распространять их. Чтобы вникнуть в саму идею, придется немного напрячься, но я уверен, что дело того стоит. Моя цель — помочь вам познакомиться с пул-реквестами и рассказать, какое место они занимают в процессе разработки ПО.
Что такое пул-реквест?
Пул-реквест это запрос (англ. request — «запрос») на интеграцию изменений из одной ветки в другую. Причем в ветке может быть всего один коммит одного разработчика, а может быть несколько коммитов разных авторов. В большинстве случаев пул-реквест используется для интеграции нового функционала или для исправления бага в основной ветке проекта.
Пул-реквест также содержит короткое описание изменений и причин, по которым эти изменения вносятся. Обычно между автором пул-реквеста и ревьюерами происходит обсуждение этих изменений.
Ревьюеры — это другие разработчики, работающие над этим проектом и способные дать обратную связь по вносимым изменениям. В проектах с открытым исходным кодом в роли ревьюеров обычно выступают ключевые контрибьюторы или мейнтейнеры. В других случаях (например, в вашей команде на работе) ревьюерами бывают более опытные коллеги (разработчики-сеньоры).
Вот как выглядит пул-реквест с простым описанием и ссылкой на issue (проблему) на GitHub:
Теперь, когда мы дали определение пул-реквестам, давайте посмотрим, почему они столь популярны и чем могут быть полезны.
Коммуникация
По сути пул-реквесты облегчают процесс совместной работы с другими людьми. Они позволяют сделать прозрачной коммуникацию между авторами и ревьюерами путем показа дифф-ов (diffs), коммитов (commits) и комментариев, поясняющих изменения.
До пул-реквестов изменения подтверждались по электронной почте или в IRC-каналах. Там писали название ветки или указывали набор коммитов. Чтобы смержить (слить) изменения, мейнтейнер или выпускающий разработчик должен был сравнить изменения с текущей версией кода на собственном компьютере, дать фидбэк, а потом подождать ответа с дополнительными изменениями. Согласованные изменения мержил на своей локальной машине, а затем отправлял их в общую кодовую базу. Пул-реквесты существенно упрощают весь этот процесс.
Особенно это касается крупных проектов, над которыми работают тысячи контрибьюторов. Поэтому многие из подобных проектов придерживаются именно процедуры пул-реквестов. Часто они также применяют рабочий процесс под названием «GitHub flow». GitHub flow предполагает форки целых проектов и создание пул-реквестов в этих форках.
Поначалу все это кажется страшным и непонятным, но не волнуйтесь! Просто помните, что основная идея остается прежней: вы запрашиваете разрешение на перенос изменений из одной ветки в другую.
Еще одно преимущество процедуры пул-реквестов в том, что всем сотрудникам видна вся коммуникация по изменениям. К вашим услугам поиск по внесенным изменениям и возможность использовать теги. В общем, отслеживать происходящее относительно легко. Контекст и предыдущие решения не теряются где-то в потоках электронных писем или окнах чатов. Любой разработчик, участвующий в проекте, может легко найти и просмотреть нужные сведения.
Автоматизация
Поскольку пул-реквесты приобрели огромную популярность в сообществе разработчиков, GitHub и другие подобные платформы создали обширный набор вебхуков (webhooks), спроектированных на основе GitHub flow. Эти вебхуки делают возможной автоматизацию работы. В наши дни распространена практика, когда задачи непрерывной интеграции выполняются при каждом коммите, и поэтому являются частью пул-реквеста. По своему опыту могу судить, что это одно из самых подходящих мест для автоматизации. Речь идет не только о запуске автоматизированных тестов. Из изменений в пул-реквесте можно разворачивать целые окружения, чтобы проверить, гладко ли все прошло.
Раньше подобные инструменты интеграции были дорогими. Команде или приходилось поддерживать инфраструктуру для задач автоматизации, либо платить за сервисы. В последнее время все больше инструментов становятся доступными, а значит, настройка автоматизированных задач облегчается. Например, вы можете воспользоваться бесплатными предложениями таких компаний как Netlify и Travis.
GitHub пошел даже еще дальше и выпустил GitHub Actions. Actions позволяют вам создавать рабочие процессы автоматизации из набора отдельных маленьких задач, пригодных для компоновки. Непременно попробуйте!
Проверки статуса
Последнее большое преимущество пул-реквестов это концепция проверок статуса (status checks). Проверки статуса это просто набор задач, выполняемых для каждого коммита в пул-реквесте, и выдающих результат «успех» (success) или «провал» (failure). Это буквально чек-листы для проверки того, готовы ли изменения к отправке в кодовую базу.
Проверять можно что угодно. В большинстве команд проверки статуса состоят из автоматизированных тестов, за которыми следует проверка стиля, после которой проверяется, получил ли этот код одно или два одобрения на ревью. Изменения не могут быть слиты, пока не пройдут все эти проверки.
Стоит также остановиться на теме код-ревью. Поскольку пул-реквесты сильно улучшают возможности коммуникации и сотрудничества, естественно, что многие команды применят их в код-ревью. Таким образом прямо со страницы пул-реквеста можно осуществлять менеджмент ревьюеров, ревью и статуса запросов (одобрено или нет). Во многих крупных проектах есть даже автоматическая процедура добавления отдельных пользователей или групп к пул-реквесту — в зависимости от файлов, которые были изменены. Если хотите пример, посмотрите документацию CODEOWNERS.
Итоги
Если брать коротко, пул-реквест это просто запрос на внедрение изменений из одной ветки в другую. Несмотря на простоту концепции, пул-реквесты являются очень мощным инструментом. Именно поэтому они стали важной частью современной разработки. Пул-реквесты облегчают задачи непрерывной интеграции, код-ревью и проверки статуса, а все вместе это позволяет поддерживать высокий уровень качества кода.
Если раньше репозиторий был просто местом, где хранится код, то с появлением пул-реквестов он стал местом, где хранятся знания об этом коде.
Также пул-реквесты играют большую роль в процессе обучения. Некоторые из самых важных уроков, касающихся разработки программ, я получил в фидбэках терпеливых ревьюеров моих пул-реквестов.
Use pull requests for code review
After you’ve added files and made updates to existing code, it’s time to merge that code into your Bitbucket Cloud repository. Before you merge, you want to ensure that you maintain code quality and won’t break already existing features. To get the feedback you need for code updates and improvements, you can create a pull request that includes all the lines of code you’ve added. Pull requests provide you with a method for requesting code reviews from your colleagues and checking build status based on your most recent commit.
To use pull requests, you need a branch or a fork, so you can develop your code on a separate branch (line) from the main code base.
You can see how pull requests fit into a larger workflow example on the Workflow for Git feature branching help document.
Pull request process
Code review and collaboration are at the core of pull requests. Depending on your role, you may be an author, a reviewer, or both on one or more pull requests. The following is an illustration of how the end-to-end pull request process works.
Pull request authors
To find pull requests you’ve created, check the Your pull requests list on the Your work dashboard.
As a pull request author, the code review process officially begins after you create the pull request with reviewers. If you don’t add reviewers during creation, you can always edit the pull request to add them afterwards.
After you’ve created a pull request and added reviewers, you might be inclined to take a break while you wait for approvals. However, as reviewers look at your code and make comments, you’ll receive email notifications of the ongoing discussion in the pull request, giving you an opportunity to respond and making you become an active participant in the code review process.
Pull request reviewers
To find requests you’ve been asked to review, check the Pull requests to review list on the Your work dashboard. You can also go to the Pull requests page of your workspace’s repositories to help your colleagues with other pull requests where you’re not listed as a reviewer.
When a workspace member adds you as a reviewer, we’ll notify you by email. After the initial notification about pull request creation, you’ll continue to get email notifications for the following actions:
The author makes updates
Another user makes a comment
Another reviewer approves
Another user merges the pull request
To disable notifications, you can unwatch the pull request.
During your code review, you’ll comment with feedback, suggestions, and ideas. You may take time to consider if there are any obvious logic errors, all cases are fully implemented, existing automated tests need to be rewritten, and the code conforms to existing style guidelines.
After your review, if the pull request is ready to be merged (or if you trust the author to resolve your tasks before merging), click the Approve button in the top right. A green checkmark appears next to your name in the Reviewers field after you approve a pull request.
If your workspace is on a Premium plan, repository admins can prevent pull requests that don’t have a certain number of approvals from being merged.
Try the new pull request experience in Bitbucket
Check out upcoming changes and our plans for adding new functionality to the pull request interface.
Create a pull request
Create a pull request to get your code reviewed before merging your changes.
Review code in a pull request
Review code in a pull request to compare changes made to the original code and add comments and feedback.
Check build status in a pull request
See the build status for the most recent commit to the repository.
Merge a pull request
Merge a pull request when the desired number of reviewers have approved it.
Resolve merge conflicts
Resolve merge conflicts when someone else has made changes to the same code you touched.
Decline a pull request
Decline a pull request when you don’t want to merge the changes in their current state.
Практическое занятие «Процесс Pull request на GitHub»
На предыдущем занятии Используем клиент GitHub для десктопа, мы использовали Github Desktop для управления рабочим процессом коммитов, ветвления и слияния. На этом занятии мы будем выполнять аналогичные действия, но с использованием браузерного интерфейса, который предоставляет Github, вместо использования терминала или Github Desktop.
Понимание процесса Pull request является важным для анализа изменений в опен-сорс проекте с несколькими участниками. Использование интерфейса GitHub также удобно, если рецензенты не знакомы с терминалом или Github Desktop.
Создание изменение в отдельной ветке
По умолчанию в новом репозитории есть одна ветка с именем «Master». Обычно, когда при внесении изменений или просмотра / редактировании, создается новая ветка и вносятся все изменения в ветку. Затем, по окончании, владелец репо объединяет изменения из новой ветки в «Master» через «pull request».
Для создания изменений в отдельной ветке:
При создании новой ветки, содержимое из главной (или любой другой ветки, которая сейчас просматривается) копируется в новую ветку. Процесс похож на «Сохранить как» с существующим документом.
Рецензенты могут продолжать вносить изменения таким образом, пока не закончат просмотр всей документации. Все изменения делаются в этой новой ветке, а не в мастере.
Создание Pull request
Для создания Pull request:
Когда мы сравниваем ветку с мастером, мы увидим список всех изменений. Мы можем просмотреть изменения в двух режимах просмотра: Unified или Split (это вкладки, показанные справа от содержимого). Unified показывает правки вместе в одной области содержимого, тогда как split показывает два файла рядом.
Владелец репозитория увидит pull request и сможет принять меры для его объединения.
Процесс Pull request
Теперь посмотрим на процесс со стороны владельцем проекта, который получил новый Pull request. Владельцу нужно обработать Pull request и объединить ветку sme-review с “Master”.
Также стоит обратить внимание, что если запрос на извлечение выполняется для более старой версии мастера, где исходное содержимое мастера больше не существует или перемещено в другое место, процесс слияния будет более трудным для выполнения.
Ветка sme-review объединяется с мастером. Теперь “Master” и ветка sme-review совпадают (ветки “смержены”).
Если посмотреть на список веток, то после удаления ветка sme-review больше не отображается.
Добавление участников в проект
Иногда необходимо добавлять соавторов в проект Github, чтобы они могли вносить изменения в ветку. Если другие участники проекта, не являясь соавторами, захотят внести изменения, они получат сообщение об ошибке. (Inviting collaborators to a personal repository)
Человек без прав на запись, может “форкнуть” (скопировать) репо, а не вносить изменения в ветку в том же проекте. Однако копирование проекта клонирует весь репозиторий, а не создает ветку в том же репозитории. Форк (копия) будет существовать в учетной записи пользователя GitHub. Можно объединить форкнутый репозиторий (это типичная модель для опен-сорс проектов со многими внешними участниками), но этот сценарий, вероятно, менее распространен для технических писателей, работающих с разработчиками в тех же проектах.
Для добавления соавторов в проект:
