Что такое pull request: Лучший 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.

Итоги

Если брать коротко, пул-реквест это просто запрос на внедрение изменений из одной ветки в другую. Несмотря на простоту концепции, пул-реквесты являются очень мощным инструментом. Именно поэтому они стали важной частью современной разработки. Пул-реквесты облегчают задачи непрерывной интеграции, код-ревью и проверки статуса, а все вместе это позволяет поддерживать высокий уровень качества кода.

Если раньше репозиторий был просто местом, где хранится код, то с появлением пул-реквестов он стал местом, где хранятся знания об этом коде.

Также пул-реквесты играют большую роль в процессе обучения. Некоторые из самых важных уроков, касающихся разработки программ, я получил в фидбэках терпеливых ревьюеров моих пул-реквестов.

GitHub как пользоваться, 12 возможностей

Хоть убейте, не могу придумать никакого вступления, так что…

#1 Редактирование кода на GitHub.com

Начну с того, что, как мне кажется, и так всем известно (хотя лично я и не подозревал об этом еще неделю назад).

При просмотре любого текстового файла на сайте GitHub, в любом репозитории, справа сверху можно видеть маленький карандашик. Если щёлкнуть по нему, можно будет отредактировать этот файл. По завершении, нажмите Propose file change («Предложить изменение файла») и GitHub создаст разветвление репозитория (fork) и запрос на внесение изменений (Pull Request).

Поразительно, не правда ли? Он сам создает fork!

Нет нужды делать форк и загружать к себе код, вносить локально изменения и отправлять обратно на GitHub c Pull Request’ом. Очень удобно, если нужно внести минимальные правки.
не совсем настоящий Pull Request

#2 Вставка изображений

Описания проблем не ограничиваются только текстовыми комментариями. Знаете ли вы, что можно вставлять изображения прямо из буфера обмена? При вставке вы увидите, его загрузку (несомненно, в «облако») и превращение в разметку для отображения изображения. Изящно!

#3 Форматирование кода

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

Но если вы размещаете фрагмент кода на таких языках программирования, как Vue, Typescript или JSX, то можете явным образом указать язык, чтобы подсветка синтаксиса была правильной.

Обратите внимание на «`jsx в первой строке:
…обеспечивающий правильное отображение фрагмента кода:
(это распространяется и на Gist, кстати. Если указать для гиста расширение .jsf, будет подсвечиваться синтаксис JSF).

Вот список всех поддерживаемых синтаксисов.

#4 Закрытие проблем при помощи «магических слов» в Pull Request’ах

Допустим, вы создаете Pull Request, исправляющий проблему #234. Вы можете вставить текст «исправляет проблему #234» в описание вашего запроса (или в любом месте любого комментария к запросу на изменение).

После этого слияние Pull Request’а «автомагически» закроет проблему. Круто, не так ли?

Вот больше информации об этом в документации.

#5 Ссылка на комментарии

Требовалось ли вам когда-нибудь создать ссылку на конкретный комментарий, а вы не знали, как это сделать? Эти дни давно прошли, поскольку я раскрою вам секрет: для создания ссылки на комментарий нужно просто щелкнуть на дате/времени рядом с названием.
Смотрите, у gaearon’а теперь есть фотка!

#6 Ссылка на код

Итак, вы хотите создать ссылку на конкретную строку кода. В таком случае, попробуйте следующее: щелкните на номере строки рядом с нужным кодом в открытом файле.

Ух ты, видите? URL поменялся, в нём теперь виден номер строки! Если удерживать нажатой клавишу SHIFT и нажать на номер другой строки, то – вуаля! – URL поменяется еще раз, и будет подсвечен диапазон строк.

Этот URL теперь будет указывать на данный файл и данный диапазон строк. Но погодите, он указывает на текущую ветку. А что, если файл поменяется? Наверное, вам нужна, в этом случае, постоянная ссылка на файл в его текущем состоянии.

Я очень ленивый, так что сделал один снимок экрана для всего вышеописанного:
Кстати, насчет URL’ов…

#7 Использование URL GitHub в качестве командной строки

Перемещение по GitHub с помощью UI организовано очень удобно. Но иногда, чтобы попасть в определенное место, быстрее окажется просто набрать его в URL. Например, если мне нужно перейти в ветку, над которой я работаю и посмотреть отличия её от ветки master, я могу просто ввести

/compare/имя_ветки после имени репозитория.

После этого я попаду на страницу различий для данной ветки:
Но это отличия от ветки master, если же я работал до этого с веткой интеграции, то могу ввести в URL /compare/integration-branch. ..my-branch
Для любителей горячих клавиш: CTRL+L или CMD+L переводит курсор в строку URL (по крайней мере в браузерах Chrome и Firefox). Это, в сочетании с автодополнением браузера, значительно упрощает перемещение между ветками.

Совет от профи: воспользуйтесь стрелками для перемещения по предложениям автодополнения Chrome и нажимайте SHIFT+DELETE для удаления элементов из истории (например, после слияния ветки).

(Не знаю, будет ли легче читать эти горячие сочетания клавиш, если буду ставить в них пробел, вот так SHIFT + DELETE. Но формально «+» не является их частью, так что мне этот вариант не нравится. Именно из-за таких вещей я и не сплю по ночам, Ронда.)

#8 Создание списков для проблем

Хотите ли вы, чтобы в вашем описании проблемы присутствовал чекбокс?
И хотите ли вы, чтобы при просмотре проблемы из списка отображалась элегантная полоска вроде «2 из 5»?
Никаких проблем! Создавать интерактивные кнопки-флажки можно с помощью следующего синтаксиса:

• [ ] Screen width (integer)
• [x] Service worker support
• [x] Fetch support
• [ ] CSS flexbox support
• [ ] Custom elements

Синтаксис: пробел, дефис, пробел, открывающаяся квадратная скобка, пробел (или x), закрывающаяся квадратная скобка, пробел и какие-нибудь слова.

После этого вы сможете действительно ставить/убирать галочки с этих кнопок! Мне это, почему-то, кажется каким-то техническим волшебством. Вы можете ставить галочки! И при этом исходный текст меняется!

Страшно подумать, что они придумают дальше.

А, и если эта проблема есть на панели проекта, то там тоже будет отображаться ход выполнения:
Если вам непонятно, что я имею в виду под «панелью проекта» – читайте ниже. Всего на пару сантиметров ниже на этой странице.

#9 Панели проектов в GitHub

Для больших проектов я всегда использовал Jira. А для своих личных проектов я всегда использовал Trello. Оба этих инструмента мне очень нравятся.

Когда несколько недель назад я узнал, что GitHub предлагает свой собственный вариант, прямо на закладке Projects репозитория, я подумал, что иметь смысл продублировать набор задач, с которыми я уже работаю в Trello.
Ничего веселого тут нет

А теперь то же самое в проекте GitHub:
Постепенно ваши глаза привыкнут к неконтрастному изображению
Ради ускорения я добавил все вышеуказанное в виде заметок (notes), то есть они не являются «настоящими» проблемами (issues) GitHub.
Но мощь управления задачами в GitHub состоит в интеграции с остальным репозиторием – так что, вероятно, лучше добавить существующие проблемы из репозитория на панель.

Нажмите Add Cards в верхнем правом углу и найдите то, что хотели бы добавить. Здесь пригодится специальный синтаксис поиска: например, наберите is:pr is:open и вы сможете перетащить любой открытый Pull Request на панель, или label:bug, если нужно исправить какие-то ошибки.
А ещё можно преобразовать существующие заметки в проблемы.
И, наконец, из формы существующей проблемы, добавить её в проект в правой панели.
Она попадёт в список triage данной панели проекта, так что вы сможете выбрать, в какой столбец её поместить
Когда описание «таска» находится в том же репозитории, что и реализующий этот таск код, это очень (ооооочень) удобно. Это значит, что через много лет вы сможете выполнить команду git blame для какой-либо строки кода и выяснить всю подоплёку задачи, которая к этой строке привела, без того, чтобы отслеживать это всё в Jira/Trello/еще где-нибудь.

Недостатки

Последние три недели я экспериментировал с выполнением всех задач в GitHub вместо Jira (на маленьком проекте, примерно в стиле Канбан) и мне это понравилось.

Но я не могу себе представить это для scrum-проекта, где необходимо оценивать и подсчитывать должным образом скорость разработки и тому подобное.
Хорошая новость: у проектов GitHub настолько мало «особенностей», что переход на другую систему не займет, в случае чего, много времени. Так что попробуйте, посмотрим, насколько вам понравится.

Не знаю, насколько это важно, но я слышал про ZenHub и открыл его впервые 10 минут назад. Фактически это расширение GitHub, в котором можно оценивать проблемы и создавать «epics» и зависимости. Там есть графики скорости разработки и выгорания; похоже, что это просто потрясающая вещь.

Дальнейшее чтение: документация GitHub по Projects.

#10 Gwiki

Для неструктурированного набора страниц – подобного Википедии – GitHub Wiki (которую я буду далее называть просто Gwiki) просто великолепна.

Для структурированного же набора страниц – например, как ваша документация – уже не настолько. Отсутствует возможность указать, что «вот эта страница – дочерняя по отношению к вот той», нет таких удобных вещей, как кнопки «Следующий раздел» и «Предыдущий раздел». Гензель и Гретель тут бы точно заблудились, потому что «хлебных крошек» (специальных отладочных операторов – прим. перев.) тут тоже нет.

(Примечание автора: Вы читали эту историю? Она просто бесчеловечна. Двое юных отморозков убивают несчастную голодную старушку, сжигая её заживо в её собственной печи. И конечно же, оставляя непонятно кому полный беспорядок. Мне кажется, именно поэтому молодежь в наши дни адски чувствительна – в наши дни сказки, читаемые детям перед сном, недостаточно жестоки!)

Продолжаем – чтобы попробовать Gwiki на деле, я ввел несколько страниц из NodeJS в качестве страниц вики, после чего создал пользовательскую боковую панель, чтобы смоделировать реальную структуру сайта. Эта боковая панель находится там постоянно, хотя текущая страница и не подсвечивается.

Ссылки придется поддерживать вручную, но в целом все работает отлично. Если хотите, можете взглянуть:
Это вряд ли может соперничать с чем-то вроде GitBook (который используется в документации Redux) или сделанным на заказ веб-сайтом. Но это уже добрых 80% от него и все прямо в вашем репозитории. Я просто фанат этого.

Предлагаю: если вы уже переросли этап использования одного файла README.md и вам нужно несколько различных страниц для руководств пользователя или более подробной документации, имеет смысл остановиться на Gwiki.

Если же отсутствие структуры/навигации вам мешает, переходите на что-либо ещё.

#11 GitHub Pages

Возможно, вы уже знали, что GitHub Pages можно использовать для размещения статического сайта. А если не знали, то знаете теперь. Однако этот раздел посвящен более узкому вопросу: использованию Jekyll для создания сайта.

В простейшем варианте, GitHub Pages + Jekyll могут визуализировать файл README.md с использованием приятной глазу темы. Например, взгляните на мою страницу readme из about-github:
Если нажать на закладку settings («настройки») для этого сайта на GitHub, включить GitHub Pages и выбрать тему Jekyll. ..
То мы получим страницу в стиле темы Jekyll:
После этого можно создать целый статический сайт на основе, главным образом, легко редактируемых файлов разметки, по существу, превращая GitHub в CMS.

Хотя фактически я этого не ис

Отправить PR в чужой репозиторий на github

Pull Request (PR) — это запрос на включение сделанных вами изменений. Официальная GitHub дока по Pull Requests.

Как известно, мы можем свободно скачивать/клонировать любые публичные репозитории любого автора на github. После того, как я склонирую себе какой-либо репозиторий, я могу вносить в него любые изменения. Изменять файлы прямо в master`е в моей копии репозитория или оформлять изменения через Pull Requests, при этом я сам же эти изменения и приму в свою копию репозитория.

Но, как сделать, чтобы автор оригинального репозитория смог увидеть мои изменения и принять их (т.е. вмерджить их) в свой (оригинальный) репозиторий? По порядку:

Создание PR в «чужой» репозиторий github 

1. Форкнуть оригинальный репозиторий
2. Склонировать форкнутый репозиторий со своего профиля
3. Привязать оригинальный репозиторий к своему
4. Внести правки в код и запушить
5. Создать PR на github

1. Нужно форкнуть репозиторий на github (кнопка fork) в свой профиль. 

2. Клонируем репозиторий к себе на компьютер из своего профиля:

cd /var/projects
git clone [email protected]:bopoda/repo.git repo

3. Привязываем оригинальный репозиторий к своему.

Только что склонированный репозиторий имеет только одну привязку к удалённому репозиторию. Она называется origin и указывает на вашу копию на GitHub (ваш профиль), а не на оригинальный репозиторий. Чтобы иметь привязку и к оригинальному репозитоирию, нужно добавить ещё одни привязку, назовём её upstream:

cd repo
git remote add upstream git://github.com/origin-name/repo.git
git fetch upstream

Теперь мы можем полноценно работать с репозиторием, как вливать, так и забирать всё что в репе есть.

4. Вносим правки в код. Можно вносить изменения в файлы и коммитить их. Можно прямо в master, но, лучше для каждой фичи создавать отдельную ветвь:

cd repo
git checkout -b master_feature #создаём новую ветвь и переключаемся на неё
git add filename
git commit -m 'implement mega feature'
git push origin master_feature  #загружает изменения из текущей локальной ветви в origin ветвь

5. Создаём ПР. Заходим на github на страницу оригинального репозитория. Создам Pull Request на основе созданной нами ветви. Обычно github уже видит созданную ветвь, которая не смерджена с мастером, и сам предлагает создать PR к ней.

После создания ПР ваши изменения будут видны всем пользователям. После проверки ПР, изменения могут быть вмерджены авторами (точнее сказать не авторами, а теми, кто имеет право на запись — push). Или же могут быть запрошены корректировки кода, которые потребуют дополнительных комментариев или даже новых коммитов от вас.

Как стать контрибутором на github?

После того, как ваши изменения пройдут проверку и будут вмерджены в основную ветвь репозитория, вы сможете себя найти в списке сontributors репозитория. Контрибуторы — это те пользователи, которые внесли свой вклад (хотя бы одну строчку) в развитие проекта.

Что делать, если разработка заняло долгое время и оригинальный репозиторий успел уйти вперёд?

Как обновиться с оригинального репозитория?

Нужно скачать последние изменения с оригинального (upstream) репозитория и вмерджить их в свой:

git checkout master
git pull upstream master
git merge upstream/master

Дата добавления:
6 лет назад

Просмотров: 364

запросов на извлечение | Учебник Atlassian Git

Pull-запросы — это функция, которая упрощает совместную работу разработчиков с помощью Bitbucket. Они предоставляют удобный веб-интерфейс для обсуждения предлагаемых изменений перед их интеграцией в официальный проект.

В своей простейшей форме запросы на вытягивание — это механизм, с помощью которого разработчик уведомляет членов команды о том, что они выполнили функцию. Как только их функциональная ветка готова, разработчик отправляет запрос на вытягивание через свою учетную запись Bitbucket.Это позволяет всем участникам узнать, что им необходимо просмотреть код и объединить его с ветвью master .

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

По сравнению с другими моделями совместной работы это формальное решение для обмена коммитами значительно упрощает рабочий процесс.SVN и Git могут автоматически отправлять уведомления по электронной почте с помощью простого скрипта; однако, когда дело доходит до обсуждения изменений, разработчикам обычно приходится полагаться на цепочки писем. Это может стать случайным, особенно когда задействованы последующие коммиты. Запросы на вытягивание помещают всю эту функциональность в удобный веб-интерфейс рядом с вашими репозиториями Bitbucket.

Анатомия запроса на вытягивание

Когда вы отправляете запрос на вытягивание, все, что вы делаете, это запрашивает у другого разработчика (например.g., сопровождающий проекта) тянет ветку из вашего репозитория в свой репозиторий. Это означает, что вам нужно предоставить 4 части информации для подачи запроса на вытягивание: исходный репозиторий, исходная ветка, целевой репозиторий и конечная ветка.

Bitbucket устанавливает для многих из этих значений разумные значения по умолчанию. Однако в зависимости от вашего рабочего процесса совместной работы вашей команде может потребоваться указать разные значения. На приведенной выше диаграмме показан пул-реквест, который просит объединить функциональную ветку с официальной главной ветвью, но есть много других способов использования пул-реквестов.

Как это работает

Запросы на извлечение

можно использовать в сочетании с рабочим процессом Feature Branch, рабочим процессом Gitflow или рабочим процессом разветвления. Но для запроса на вытягивание требуются либо две отдельные ветви, либо два отдельных репозитория, поэтому они не будут работать с централизованным рабочим процессом. Использование запросов на вытягивание с каждым из этих рабочих процессов немного отличается, но общий процесс выглядит следующим образом:

1. Разработчик создает функцию в выделенной ветке своего локального репо.

2. Разработчик помещает ветку в общедоступный репозиторий Bitbucket.

3. Разработчик отправляет запрос на вытягивание через Bitbucket.

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

5. Сопровождающий проекта объединяет функцию в официальный репозиторий и закрывает запрос на перенос.

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

Feature Branch Workflow с запросами на извлечение

Рабочий процесс Feature Branch Workflow использует общий репозиторий Bitbucket для управления совместной работой, а разработчики создают функции в изолированных ветвях. Но вместо того, чтобы сразу объединять их в master , разработчики должны открыть запрос на вытягивание, чтобы инициировать обсуждение функции, прежде чем она будет интегрирована в основную кодовую базу.

В рабочем процессе Feature Branch есть только один общедоступный репозиторий, поэтому репозиторий назначения запроса на вытягивание и исходный репозиторий всегда будут одинаковыми.Обычно разработчик указывает свою функциональную ветвь как исходную, а главную ветвь как целевую.

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

Также можно отправить запрос на вытягивание для незавершенной функции. Например, если у разработчика возникают проблемы с реализацией определенного требования, он может отправить запрос на вытягивание, содержащий информацию о незавершенной работе. Затем другие разработчики могут предоставить предложения внутри запроса на перенос или даже сами решить проблему с помощью дополнительных коммитов.

Рабочий процесс Gitflow с запросами на извлечение

Рабочий процесс Gitflow похож на рабочий процесс Feature Branch, но определяет строгую модель ветвления, разработанную для выпуска проекта.Добавление запросов на вытягивание в рабочий процесс Gitflow дает разработчикам удобное место для обсуждения ветки выпуска или ветки обслуживания, пока они работают над ней.

Механика запросов на вытягивание в рабочем процессе Gitflow точно такая же, как и в предыдущем разделе: разработчик просто отправляет запрос на вытягивание, когда необходимо проверить ветку функции, выпуска или исправления, а остальная часть команды будет уведомлена через Bitbucket.

Функции

обычно объединяются в ветвь develop , а ветви выпуска и исправления объединяются в обе ветви develop и master .Запросы на вытягивание можно использовать для формального управления всеми этими слияниями.

Форкинг рабочего процесса с запросами на извлечение

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

Аспект уведомления о запросах на вытягивание особенно полезен в этом рабочем процессе, потому что сопровождающий проекта не имеет возможности узнать, когда другой разработчик добавил коммиты в свой репозиторий Bitbucket.

Поскольку каждый разработчик имеет свой собственный общедоступный репозиторий, исходный репозиторий запроса на вытягивание будет отличаться от целевого репозитория. Исходный репозиторий — это общедоступный репозиторий разработчика, а исходная ветвь — это та, которая содержит предлагаемые изменения. Если разработчик пытается объединить эту функцию с основной кодовой базой, то целевой репозиторий является официальным проектом, а конечная ветвь — master .

Запросы на извлечение

также можно использовать для сотрудничества с другими разработчиками вне официального проекта.Например, если разработчик работал над функцией с товарищем по команде, он мог подать запрос на вытягивание, используя репозиторий Bitbucket товарища по команде для места назначения вместо официального проекта. Затем они будут использовать одну и ту же функциональную ветвь для исходной и целевой ветвей.

Два разработчика могли обсудить и разработать эту функцию внутри запроса на вытягивание. Когда они будут готовы, один из них отправит еще один запрос на перенос с просьбой объединить эту функцию с официальной главной веткой.Такая гибкость делает запросы на вытягивание очень мощным инструментом совместной работы в рабочем процессе Forking.

Пример

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

В этом примере Мэри — разработчик, а Джон — сопровождающий проекта. У обоих есть свои собственные публичные репозитории Bitbucket, а у Джона есть официальный проект.

Мэри является форком официального проекта

Чтобы начать работу над проектом, Мэри сначала нужно разветвить репозиторий Bitbucket Джона. Она может сделать это, войдя в Bitbucket, перейдя в репозиторий Джона и нажав кнопку Fork .

После ввода имени и описания разветвленного репозитория у нее будет серверная копия проекта.

Мэри клонирует свой репозиторий Bitbucket

Затем Мэри нужно клонировать репозиторий Bitbucket, который она только что разветвила.Это даст ей рабочую копию проекта на ее локальном компьютере. Она может сделать это, выполнив следующую команду:

  git clone https: //[email protected]/user/repo.git  

Имейте в виду, что git clone автоматически создает удаленный origin , который указывает на разветвленный репозиторий Мэри.

Мэри разрабатывает новую функцию

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

  git checkout -b some-feature # Отредактируйте код git commit -a -m «Добавить первый черновик некоторой функции»  

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

Мэри помещает эту функцию в свой репозиторий Bitbucket

После того, как ее функция завершена, Мэри помещает ветку функции в свой собственный репозиторий Bitbucket (не официальный репозиторий) с помощью простого git push :

  git push origin some-branch  

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

Мэри создает запрос на вытягивание

После того, как Bitbucket получит свою функциональную ветку, Мэри может создать запрос на вытягивание через свою учетную запись Bitbucket, перейдя в свой разветвленный репозиторий и нажав кнопку Pull request в правом верхнем углу. Полученная форма автоматически устанавливает репозиторий Мэри в качестве исходного репозитория и просит ее указать исходную ветвь, целевой репозиторий и целевую ветвь.

Мэри хочет объединить свою функцию с основной базой кода, поэтому исходная ветвь является ее ветвью функции, целевым репозиторием является общедоступный репозиторий Джона, а конечной ветвью является master .Ей также необходимо указать заголовок и описание запроса на перенос. Если есть другие люди, которым необходимо утвердить код помимо Джона, она может ввести их в поле Reviewers .

После того, как она создаст пул-реквест, Джону будет отправлено уведомление через его канал Bitbucket и (необязательно) по электронной почте.

Джон просматривает запрос на вытягивание

Джон может получить доступ ко всем запросам на извлечение, которые подали люди, щелкнув вкладку Запрос на извлечение в своем собственном репозитории Bitbucket.Нажав на запрос на перенос, Мэри покажет ему описание запроса на перенос, историю фиксации функции и все изменения, которые он содержит.

Если он думает, что функция готова к слиянию с проектом, все, что ему нужно сделать, это нажать кнопку Merge , чтобы утвердить запрос на вытягивание и слить функцию Мэри с его основной веткой .

Но для этого примера допустим, что Джон обнаружил небольшую ошибку в коде Мэри и нуждается в ее исправлении, прежде чем объединять.Он может либо опубликовать комментарий к запросу на перенос в целом, либо выбрать конкретную фиксацию в истории функции, чтобы прокомментировать.

Мэри добавляет последующую фиксацию

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

Чтобы исправить ошибку, Мэри добавляет еще одну фиксацию в свою ветку функций и помещает ее в свой репозиторий Bitbucket, как и в первый раз.Эта фиксация автоматически добавляется к исходному запросу на вытягивание, и Джон может снова просмотреть изменения прямо рядом со своим исходным комментарием.

Джон принимает запрос на вытягивание

Наконец, Джон принимает изменения, объединяет функциональную ветвь с главной и закрывает запрос на вытягивание. Эта функция теперь интегрирована в проект, и любые другие разработчики, работающие над ней, могут перенести ее в свои локальные репозитории с помощью стандартной команды git pull .

Куда идти дальше

Теперь у вас должны быть все инструменты, необходимые для интеграции запросов на вытягивание в существующий рабочий процесс.Помните, что запросы на вытягивание не заменяют ни один из рабочих процессов совместной работы на основе Git, а скорее удобное дополнение к ним, которое делает совместную работу более доступной для всех членов вашей команды.

Github Pull Request Basics — Learn.co

Описание проблемы

Концепция запроса на вытягивание уникальна для GitHub, поэтому не нервничайте
о незнании, что это такое! «Запрос на вытягивание» поддерживает сообщества разработчиков
которые создают и вносят свой вклад в проекты с открытым исходным кодом на GitHub.

В ходе этого процесса любой может

1. вилка репо от исходной организации
2. клонировать на локальный компьютер
3. Внести изменения в функцию , ветвь в своей локальной системе
4. толкает свою ветку к разветвленному репо

… а теперь критический шаг ….

1. Предложите, чтобы исходная организация подтянула изменения, составляющие
   функция ветки обратно в исходный репозиторий .

Вместо того, чтобы владелец работал только над своей кодовой базой, может внести любой
тесты, исправления в документации, новые функции, макет, графика и т. д. Как это
особенность работы? Это потрясающее чувство, когда ты просыпаешься и видишь, что кто-то
вы никогда не встречали улучшения вашего кода, которые они хотели бы
способствовать!

Цели

1. Объясните, что такое запрос на вытягивание
2. Определите, как создать запрос на вытягивание из вилки в репо
3. Определить, как добавить коммиты к существующему запросу на вытягивание

Объясните, что такое Pull Requests

Запрос на перенос — это запрос к владельцу другого репо, чтобы он внес изменения, которые вы
сделано в ветке на вашей вилке их репо и интегрировать его в их как
если вы выполнили работу непосредственно на их .Это просьба к собственнику
репозитория, чтобы принять ваши изменения, которые вы внесли в свою собственную копию
репо («ваша вилка») и «втяните» их в репозиторий владельца. Вот это
отличный пример запроса на извлечение на базе кода Ruby .

ПРИМЕЧАНИЕ
Термин «запросы на вытягивание» связан с распределенной природой того, сколько открытых
исходные проекты организуются сами. Вместо того, чтобы вносить изменения в
центральный репозиторий, вы публикуете свои изменения отдельно и запрашиваете
сопровождающий, чтобы внести ваши изменения.Затем сопровождающий может просмотреть изменения.
и сделай сказал тянуть. Это не то же самое, что и в git pull , который объединяет
изменения, внесенные в удаленном репо в вашу локальную версию ветки.

Определите, как создать запрос на вытягивание из вилки в репо

Давайте рассмотрим концептуальный гипотетический пример. Ничего страшного, если это немного
сначала сбивает с толку. Вы будете работать через это бесчисленное количество раз, и в конечном итоге
ваш мозг и пальцы поймут, что происходит.Посмотрим на
следующий пример:

1. Давайте представим, что у организации соучеников есть репо под названием
   awesome-lab, и мы делаем «вилку» из этого репо на
   https://github.com/learn-co-students/awesome-lab .
2. Теперь у вас будет копий этого репо в вашей учетной записи GitHub («организация»), т.е.
   https://github.com/your-user-name/awesome-lab . Технологи сказали бы
   вы «раздвоили» репо awesome-lab от организации обучающихся
   в организацию ваше имя пользователя .
3. Однако у вас все равно не будет локальной копии этого репозитория на вашем компьютере.
4. Вы бы клонировали вилку на свой компьютер. Нет причин, по которым вы не могли
   клон из оригинального репозитория . Однако большинство владельцев репо не хотят случайных
   люди в Интернете (такие как вы!), совершающие свои репо. Что ты есть
   собираюсь создать «параллельное» репо в вашей организации , а затем сообщить
   «исходный» репо «Эй, я добавил кое-что классное, прошу вытащить
   это внутри.«
5. Внесите некоторые изменения на локальном компьютере в ветку
6. Переместите свою ветку кода из локальной системы назад с на в вилку
7. Создайте запрос на извлечение , который запрашивает «втягивание» улучшенного кода в
   исходное репо. Соблюдайте следующие шаги для запуска запроса на извлечение :

Шаг 1

Шаг 2

Здесь вы можете выбрать базовую вилку, которая будет their-user-name / awesome-lab .Затем выберите головную вилку, которая будет your-user-name / awesome-lab

.

Теперь нажмите «Создать запрос на перенос», и все готово!

Что делать, если другой студент теперь разветвляет репозиторий
https://github.com/learn-co-students/awesome-lab
как https://github.com/their-user-name/awesome-lab , затем вы вносите некоторые изменения и
хотите отправить запрос на перенос на свою вилку https://github.com/their-user-name/awesome-lab ?
Как ты делаешь это?

К счастью, git не заботится о том, является ли один репозиторий «источником» или
«еще одна вилка источника.»Если завтра GitHub волшебным образом исчезнет, ​​локальные копии будут
Сотни ноутбуков по всему миру так же хороши, как и копия на GitHub !
Вот почему git называется «распределенной системой контроля версий». Итак, чтобы поделиться
запрос на вытягивание с другим студентом выполняется так же, как и форк некоторых известных
проект (например, Ruby или jQuery).

Определите, как добавить коммиты в существующий запрос на извлечение

Допустим, вы делаете запрос на перенос из
https: // github.com / your-user-name / awesome-lab в
https://github.com/learn-co-students/awesome-lab . Затем вы замечаете, что сделали
опечатка в вашем коде. Все, что вам нужно сделать, это исправить опечатку, зафиксировать ее и подтолкнуть вверх
изменения в вашей ветке. Пока запрос на перенос уже существует,
коммиты будут добавлены автоматически.

Заключение

Pull-запросы — это просто инструмент, позволяющий владельцам проектов и редакторам
сотрудничать, не предоставляя слишком много прямого доступа и не наступая на
пальцы друг друга.Это действие можно выполнить даже с репо, соавтором которого вы являетесь.
включен, но может не иметь доступа для записи — но мы пока не будем вдаваться в подробности. Вы будете
продолжать узнавать больше о сотрудничестве и о том, как git позволяет отслеживать и
редактируйте проекты сколько душе угодно!

Ознакомьтесь с основами GitHub Pull Request на Learn.co и начните бесплатное обучение программированию.

Pull Requests — pagure documentation

Pagure использует концепцию pull-запросов для внесения изменений из вашей вилки
проекта обратно в проект вверх по течению.Чтобы внести изменения в проект
вы сначала открываете запрос на перенос с исходным проектом. Сопровождающий проекта
затем объединяет запрос на перенос, если они удовлетворены внесенными вами изменениями
предложенный.

Открыть запрос на слияние

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

Pagure to Pagure pull request

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

Из обзора проекта

1. Перейдите на вкладку overview вашей вилки.

2. Найдите свою функциональную ветку (правая сторона) и нажмите кнопку New PR button.

3. Заполните форму «Создать запрос на вытягивание» (заголовок и описание) и создайте свой запрос на вытягивание.

Примечания: Кнопка New PR появляется только в том случае, если есть коммиты, недоступные в основной ветви.

Из истории коммитов

1. Перейдите на вкладку commit вашей вилки и выберите ветку функции.

2. Нажмите кнопку создать запрос на вытягивание (над последними фиксациями).

3. Заполните форму «Создать запрос на вытягивание» (заголовок и описание) и создайте свой запрос на вытягивание.

Из списка запросов на вытягивание

1. Перейдите в список запросов на вытягивание основного проекта (не вашего форка) и нажмите кнопку File Pull Request .

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

3. Заполните форму «Создать запрос на вытягивание» (заголовок и описание) и создайте свой запрос на вытягивание.

Запрос на вытягивание с удаленного Git на страницу

Вы можете создать запрос на перенос с другой хостинг-платформы git (например,грамм. GitHub, GitLab).
Это удаленный запрос на вытягивание.

Из списка запросов на вытягивание

1. Перейдите в список запросов на вытягивание основного проекта (не вашего форка) и нажмите кнопку File Pull Request .

2. Выберите опцию Remote pull-request из раскрывающегося меню.

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

Поздравляем! Теперь разработчик проекта должен принять ваши изменения.
путем их объединения.

Обновление запроса на слияние

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

Добавить в ваш пул реквест так же просто, как отправить новые коммиты в ветку, которую вы
используется для создания запроса на вытягивание. Они будут автоматически отображаться в
список фиксации для запроса на вытягивание.

Ребазинг

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

Работа с запросами на извлечение

Довольно распространено работать с запросом на вытягивание локально, либо для создания поверх
это или проверить это. Вы можете легко сделать это, используя git fetch , чтобы загрузить
запрос на вытягивание, за которым следует git checkout , чтобы работать с ним, как с любым
местное отделение.Синтаксис для git fetch :

 git fetch $ REMOTE pull / $ PR_NUMBER / head: $ BRANCHNAME
 

Например, если у вас PR # 1, который «добавляет поддержку foo», вы можете запустить:

 git fetch origin pull / 1 / head: add-foo-support
 

Тогда вы можете нормально работать с add-foo-support :

 git checkout add-foo-support
 

Примечание

Вы можете использовать / символов в названии ветки, если хотите сгруппировать
ваши запросы на вытягивание по имени отправителя, номера ошибки и т. д.За
Например, вы можете назвать местный филиал user / add-foo-support .

Если вы хотите разрешить работу со всеми вашими запросами на вытягивание локально, вы можете сделать
поэтому, отредактировав конфигурацию git следующим образом.
Найдите свой пульт в файле .git / config , например:

 [удаленное "происхождение"]
    url = ssh: //[email protected]/pagure.git
    выборка = + ссылки / головы / *: ссылки / удаленные / происхождение / *
 

Теперь добавьте эту строку:

 fetch = + refs / pull / * / head: refs / remotes / origin / pr / *
 

в этот раздел как первая строка выборки , например:

 [удаленное "происхождение"]
    url = ssh: // git @ pagure.io / pagure.git
    fetch = + refs / pull / * / head: refs / remotes / origin / pr / *
    выборка = + ссылки / головы / *: ссылки / удаленные / происхождение / *
 

Очевидно, удаленный URL-адрес должен совпадать с URL-адресом вашего проекта (проект страницы в
этот пример).

Теперь вы можете получить все запросы на вытягивание:

 $ git fetch origin
Из ssh: //pagure.io/pagure
* [новая ссылка] refs / pull / 2541 / head -> origin / pr / 2541
* [новая ссылка] refs / pull / 2540 / head -> origin / pr / 2540
* [новая ссылка] refs / pull / 2538 / head -> origin / pr / 2538
 

Для оформления конкретного запроса на вытягивание:

 $ git checkout пр / 25413
Отделение пр / 2541 настроено для отслеживания удаленного отделения пр / 2541 от источника.Перешел в новую ветку пр / 2541
 

Теперь вы сможете использовать эту ветвь для работы с запросами на вытягивание или с ними.

Если вас интересует только один конкретный запрос на перенос и вы не хотите получать все PR проекта,
вы можете добавить в свой ~ / .bashrc следующую функцию:

 function pullpr {
    удаленный = "$ {2: -origin}"
    git fetch $ remote pull / $ 1 / голова: pr_ $ 1
    git checkout pr_ $ 1
}
 

Затем после получения вашего ~ / .bashrc или перезапуска оболочки вы можете использовать
pullpr для проверки запроса на перенос из клона репозитория git.Например, запрос на извлечение № 58 из текущего клона git (здесь
Infra-docs проект)

 $ источник ~ / .bashrc
$ pullpr 58
удаленный: Подсчет объектов: 393, готово.
remote: Сжатие объектов: 100% (238/238), готово.
удаленный: Всего 365 (дельта 231), повторно 255 (дельта 127)
Прием объектов: 100% (365/365), 71.36 Кбайт | 63.00 КБ / с, готово.
Разрешение дельт: 100% (231/231), выполнено 20 локальных объектов.
Из ssh: //pagure.io/infra-docs
* [новая ссылка] refs / pull / 58 / head -> pr_58
Перешел на ветку pr_58
 

.