push request git что это
Внесение собственного вклада в проекты
Теперь наша учётная запись создана и настроена, давайте же пройдёмся по деталям, которые будут полезны при внесении вклада в уже существующие проекты.
Создание ответвлений (fork)
Если вы хотите вносить свой вклад в уже существующие проекты, в которых у нас нет прав на внесения изменений путём отправки (push) изменений, вы можете создать своё собственное ответвление (fork) проекта. Это означает, что GitHub создаст вашу собственную копию проекта, данная копия будет находиться в вашем пространстве имён и вы сможете легко делать изменения путём отправки (push) изменений.
Исторически так сложилось, что англоязычный термин «fork» (создание ветвления проекта) имел негативный контекстный смысл, данный термин означал, что кто-то повёл или ведёт проект с открытым исходным кодом в другом, отличном от оригинала, направлении, иногда данный термин так же означал создание конкурирующего проекта с раздельными авторами. В контексте GitHub, «fork» (создание ветвления проекта) просто означает создание ветвления проекта в собственном пространстве имён, что позволяет вносить публичные изменения и делать свой собственный вклад в более открытом виде.
Таким образом, проекты не обеспокоены тем, чтобы пользователи, которые хотели бы выступать в роли соавторов, имели право на внесение изменений путём их отправки (push). Люди просто могут создавать свои собственные ветвления (fork), вносить туда изменения, а затем отправлять свои внесённые изменения в оригинальный репозиторий проекта путём создания запроса на принятие изменений (Pull Request), сами же запросы на принятие изменений (Pull Request) будут описаны далее. Запрос на принятие изменений (Pull Request) откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждении предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект.
Для того, чтобы создать ответвление проекта, зайдите на страницу проекта и нажмите кнопку «Создать ответвление» («Fork»), которая расположена в правом верхнем углу.
Через несколько секунд вы будете перенаправлены на собственную новую проектную страницу, содержащую вашу копию, в которой у вас есть права на запись.
Рабочий процесс с использованием GitHub
GitHub разработан с прицелом на определённый рабочий процесс с использованием запросов на слияния. Этот рабочий процесс хорошо подходит всем: и маленьким, сплочённым вокруг одного репозитория, командам; и крупным распределённым компаниям, и группам незнакомцев, сотрудничающих над проектом с сотней копий. Рабочий процесс GitHub основан на тематических ветках, о которых мы говорили в главе Ветвление в Git.
Вот как это обычно работает:
Создайте форк проекта.
Создайте один или несколько коммитов с изменениями, улучшающих проект.
Отправьте эту ветку в ваш проект на GitHub.
Откройте запрос на слияние на GitHub.
Обсуждайте его, вносите изменения, если нужно.
Владелец проекта принимает решение о принятии изменений, либо об их отклонении.
Получите обновлённую ветку master и отправьте её в свой форк.
Очень напоминает подход, описанный в разделе Диспетчер интеграции главы 5, но вместо использования электронной почты, команда сотрудничает через веб-интерфейс.
Давайте посмотрим, как можно предложить изменения в проект, размещённый на GitHub.
В большинстве случаев можно использовать официальный инструмент GitHub CLI вместо веб-интерфейса GitHub. Инструмент доступен в системах Windows, MacOS и Linux. Посетите страницу GitHub CLI homepage для получения инструкций по установке и использованию.
Создание запроса на слияние
Тони ищет, чего бы запустить на своём новеньком Arduino. Кажется, он нашёл классный пример на https://github.com/schacon/blink.
Единственная проблема в том, что светодиод моргает слишком быстро; нам кажется, лучше установить задержку в три секунды, не одну. Так давайте исправим это и предложим изменения автору.
Клонируем нашу копию
Создаём тематическую ветку
Вносим свои изменения
Фиксируем изменения в тематической ветку
Отправляем новую ветку в нашу копию на GitHub
Теперь, если мы зайдём на страничку нашей копии на GitHub, мы увидим, что GitHub заметил наши изменения и предлагает открыть запрос на слияние с помощью большой зелёной кнопки.
Также можно зайти на страницу «Branches», по адресу https://github.com/ /
Если нажать на эту кнопку, появится экран ввода заголовка и описания предлагаемых изменений на рассмотрение владельцу проекта. Рекомендуется серьёзно подойти к составлению описания и сделать его максимально информативным, чтобы владелец проекта понимал, зачем эти изменения и какую пользу они принесут.
Также мы видим список коммитов в нашей тематической ветке, «опередивших» ветку master (в данном случае всего один коммит) и предпросмотр всех изменений, вносимых этими коммитами.
После создания запроса на слияние (путём нажатия кнопки «Create pull request» на этой странице) владелец форкнутого проекта получит уведомление о предложенных изменениях со ссылкой на страницу с информацией о запросе.
Запросы на слияние широко используются для публичных проектов типа описанного выше, когда участник уже подготовил все изменения для слияния с основным репозиторием. Тем не менее, часто можно встретить использование запросов на слияние во внутренних проектах в самом начале цикла разработки. Обьяснение простое: вы можете обновлять тематическую ветку после открытия запроса на слияние, поэтому сам запрос открывается как можно раньше чтобы отслеживать прогресс разработки.
Обработка запроса на слияние
На этом этапе, владелец проекта может просмотреть предложенные изменения, принять, отклонить или прокомментировать их. Предположим, ему импонирует идея, но он предпочёл бы большую задержку перед включением или выключением света.
В то время как в главе Распределенный Git обсуждение изменений может производится через электронную почту, на GitHub всё происходит онлайн. Владелец проекта может просмотреть суммарные изменения, вносимые запросом, и прокомментировать любую отдельно взятую строку.
Как только владелец прокомментирует изменения, автор запроса на слияние (а также все подписавшиеся на этот репозиторий) получат уведомления. Далее мы рассмотрим как настроить уведомления, но сейчас, если Тони включил уведомления через электронную почту, он получит следующее письмо:
Кто угодно может оставлять комментарии к запросу на слияние. На Страница обсуждения запроса на слияние можно увидеть пример, где владелец проекта оставил комментарии как к строке кода, так и в основной секции обсуждения. Как вы могли заметить, комментарии к коду так же приведены в виде обсуждения.
Теперь участник может видеть что ему необходимо сделать для того, чтобы его изменения были приняты. К счастью, это тоже легко сделать. Используя почту, вам потребуется заново отправить свои изменения в список рассылки, а при использовании GitHub вы просто делаете коммит в тематическую ветку и повторяете push, что автоматически обновляет запрос на слияние. На рисунке Финальная стадия запроса на слияние также видно, что в обновленном запросе на слияние старый комментарий к коду был свёрнут, так как он относится к строке, которая с тех пор изменилась.
Когда участник сделает это, владелец проекта снова получит уведомление, а на странице запроса будет отмечено, что проблема решена. Фактически, как только строка кода имеющая комментарий будет изменена, GitHub заметит это и удалит устаревшее отличие.
Примечательно, что если вы перейдёте на вкладку «Files Changed» в этом запросе на слияние, то увидите «унифицированную» разницу — это суммарные изменения, которые будут включены в основную ветку при слиянии тематической ветки. В терминологии git diff это эквивалентно команде git diff master…
для ветки, на которой основан этот запрос на слияние. В Определение применяемых изменений детальнее описан данный тип отличий.
GitHub так же проверяет может ли запрос на слияние быть применён без конфликтов и предоставляет кнопку для осуществления слияния на сервере. Эта кнопка отображается только если у вас есть права на запись в репозиторий и возможно простейшее слияние. По нажатию на неё GitHub произведёт «non-fast-forward» слияние, что значит даже если слияние может быть осуществлено перемоткой вперед, всё равно будет создан коммит слияния.
При желании, можно стянуть ветку и произвести слияние локально. Если эта ветка будет слита в master ветку и отправлена на сервер, то GitHub автоматически закроет запрос на слияние.
Это основной рабочий процесс, который используется большинством проектов на GitHub. Создаются тематические ветки, открываются запросы на слияние, производится обсуждение, при необходимости производятся доработки в ветке и, наконец, запрос либо закрывается, либо сливается.
Важно отметить, что можно открывать запросы на слияние между двумя ветками в одном репозитории. Если вы работаете над функционалом с кем-то ещё и у вас обоих есть права записи, то вы можете отправить свою тематическую ветку в репозиторий и открыть запрос на слияние в master ветку в рамках одного проекта, что позволит инициировать процедуру проверки кода и его обсуждения. Создание ответвлений проекта не является обязательным.
Продвинутые запросы на слияние
На текущий момент мы рассмотрели основы участия в проекте на GitHub, давайте рассмотрим некоторые интересные секреты и уловки касательно запросов слияния, чтобы вы могли более эффективно их использовать.
Запросы слияния как Патчи
Важно понимать, что многие проекты не воспринимают запросы слияния как очередь идеальных патчей, которые должны применяться аккуратно и по порядку, как и большинство проектов, участие в которых основывается на отправке набора патчей через списки почтовых рассылок. Большинство проектов на GitHub понимают ветки запросов на слияние как беседу относительно предлагаемого изменения, завершающуюся слиянием унифицированных изменений.
Это важное различие, так как изменение предлагается до того, как код станет считаться идеальным, что гораздо реже происходит с распространяемыми наборами патчей через списки рассылок. Обсуждение происходит на более раннем этапе и выработка правильного решения происходит за счёт усилий сообщества. Когда код предлагается через запрос на слияние и сопровождающий проекта или сообщество предлагает изменения, то не применяется набор патчей, а отправляются результирующие изменения как новый коммит в ветку, двигая обсуждение вперёд и сохраняя уже проделанную работу нетронутой.
Например, если вы вернётесь и посмотрите на Финальная стадия запроса на слияние, то увидите, что участник не делал перебазирование своего коммита и не отправлял новый запрос на слияние. Вместо этого были сделаны новые коммиты и отправлены в существующую ветку. Таким образом, если вы в будущем вернётесь к этому запросу слияния, то легко найдёте весь контекст принятого решения. По нажатию кнопки «Merge» целенаправленно создаётся коммит слияния, который указывает на запрос слияния, оставляя возможность возврата к цепочке обсуждения.
Следование за исходным репозиторием
Если ваш запрос на слияние устарел или не может быть слит без конфликтов, то вам нужно изменить его, чтобы сопровождающий мог просто его слить. GitHub проверит это за вас и под каждым из запросов на слияние отобразит уведомление, можно ли его слить без конфликтов или нет.
Если вы видите что-то вроде Запрос имеет конфликты слияния, то вам следует изменить свою ветку так, чтобы исключить конфликты и сопровождающий не делал лишнюю работу.
Существует два основных варианта это сделать. Вы можете либо перебазировать свою ветку относительно целевой ветки (обычно, относительно master ветки исходного репозитория), либо слить целевую ветку в свою.
Большинство разработчиков на GitHub выбирают последний вариант по тем же причинам, что и мы в предыдущем разделе. Важна история и окончательное слияние, а перебазирование не принесёт вам ничего, кроме немного более чистой истории, при этом оно гораздо сложнее и может стать источником ошибок.
Если вы хотите сделать запрос на слияние применяемым, то следует добавить исходный репозиторий как новый удалённый, слить изменения из его основной ветки в вашу тематическую, если имеются исправить все проблемы и, наконец, отправить все изменения в ту ветку, на основании которой был открыт запрос на слияние.
Предположим, что в примере «tonychacon», который мы использовали ранее, основной автор сделал изменения, которые конфликтуют с запросом на слияние. Рассмотрим это пошагово.
Получаем последние изменения из него.
Сливаем основную ветку в нашу тематическую.
Исправляем указанный конфликт.
Отправляем изменения в ту же тематическую ветку.
Как только это будет сделано, запрос на слияние будет автоматически обновлён и перепроверен на возможность слияния.
Если вы очень хотите перебазировать ветку, чтобы её почистить, то, конечно, вы можете это сделать, но настоятельно не рекомендуется переписывать ветку, к которой уже открыт запрос на слияние. Если другие люди уже стянули её и проделали много работы, то вы столкнётесь со всеми проблемами, описанными в разделе Опасности перемещения главы 3. Вместо этого, отправьте перебазированную ветку в новую на GiHub и откройте новый запрос на слияние, который указывает на предыдущий, затем закройте исходный.
Ссылки
Возможно, ваш следующий вопрос будет: «Как мне сослаться на предыдущий запрос слияния?» Оказывается, существует много способов ссылаться на другие вещи практически везде, где у вас есть права записи на GitHub.
Давайте начнём с перекрёстных ссылок для запросов слияния или проблем. Всем запросам слияния и проблемам присваиваются уникальные номера в пределах проекта. Например, у вас не может быть запроса на слияние с номером #3 и проблемы с номером #3. Если вы хотите сослаться на любой запрос слияния или проблему из другого места, просто добавьте # в комментарий или описание. Так же можно указывать более конкретно, если проблема или запрос слияния находятся где-то ещё; пишите username# если ссылаетесь на проблему или запрос слияния, находящиеся в ответвлённом репозитории, или username/repo# если ссылаетесь на другой репозиторий.
Рассмотрим это на примере. Предположим, что мы перебазировали ветку в предыдущем примере, создали новый запрос слияния для неё и сейчас хотим сослаться на предыдущий запрос слияния из нового. Так же мы хотим сослаться на проблему, находящуюся в ответвлённом репозитории, и на проблему из совершенно другого проекта. Мы можем составить описание как указано на Перекрёстные ссылки в запросе слияния.
Когда мы отправим запрос на слияние, то увидим что-то вроде Отображение перекрёстных ссылок в запросе слияния.
Как сделать pull request
Pull Request — запрос на включение. На включение написанного вами кода в чужой репозиторий.
С чего начать?
А для начала этот самый репозиторий нужно форкнуть (fork — вилка, ответвление). Разберём это нехитрое действо на примере веб-сервиса для хостинга IT-проектов, название которому GitHub. Разумеется, кроме GitHub есть и другие: BitBucket, например. Выбирать по вкусу.
Для успешного проведения нижеизложенных операций у вас (что естественно) должен быть установлен git
В консоли в зависимости от входных данных набираем нечто подобное:
Отлично. Уже можно вносить свои изменения в код проекта.
Тот репозиторий, что теперь лежит на вашем жёстком диске, независим от основного. В нём отслеживаются только ваши наработки. Но как следить за изменениями, происходящими в первоисточнике, откуда вы « стянули » репозиторий? Добавить удаленный репозиторий в отслеживаемые. Например, так:
Давайте посмотрим как сливать изменения из оригинального репозитория к себе в случае, если разработка в нём ушла вперёд пока вы сосредоточенно писали коммиты:
Если репозиторий огромен, а забирать его весь не хочется, клонируем только нужную ветку:
Что такое ветки?
Чаще всего ветки (branch — ответвление, ветвь, филиал) бывают тематическими. Например, при общей разработке, когда у всех участников есть право записи в репозиторий. В этом случае ветки используются для отделения изменений, сделанных одним из разработчиков, от общего репозитория. Ветки могут пригодиться и в случае с созданием pull-request’а.
Создание ветки происходит довольно просто. Находясь в каталоге с проектом, наберите следующие команды:
Новые ветки создаются не только из master, берите любую!
Находясь в только что созданной ветке, вы можете приступить к работе. Вносите в код свои изменения, а когда закончите просто переключитесь обратно к своей основной ветке. Вы можете отправить pull request, выбрав ветку new_branch или же прежде слить изменения из неё в основную ветку разработки. Рассмотрим это подробнее:
Если нужно отправить в свой удалённый репозиторий вновь созданную ветку (не сливать её с master), делаем следующее:
Не торопитесь сливать изменения. Если что-то не заладилось, созданную ветку можно удалить:
Удалить все локальные ветки, которые были смержены (то есть код которых теперь есть) в ветках develop или master:
Отправляем изменения
Добрались таки до ответа на поставленный вопрос: что такое pull request, зачем оно нужно и как его достичь. Как предложить владельцу репозитория свои изменения?
Для этого зайдите в свой аккаунт, выбирайте репозиторий владельца и ищите небольшую зелёную кнопку (на момент написания поста она была таковой, если даже что-то изменится, думаю, найти её будет несложно).
А дальше. ждать. Пока придёт владелец оригинального репозитория и примет/отклонит ваши изменения.
Ну вот, мы его достигли. Просветления то есть 🙂
Как отменить изменения
Когда нужно вернуть более старое состояние уже проиндексированных файлов и забыть о них совсем (помните, что упомянутая здесь операция отменит всю вашу работу до определённого коммита!):
Cмотрим на какой коммит откатиться. В примере откатываемся назад на 1 коммит. Для изменения состояния в этой же ветке удалённого репозитория тоже придётся использовать грубую силу — флаг force :
Или посмотреть все изменения, которые происходили с отдельным файлом:
А подробнее?
Итогов подводить не стану. Для заинтересованных лиц ссылочка на неофициальную документацию: The Git Community Book
Что такое 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, не сразу, но будет указана/указан в числе контрибьюторов Вашего репозитория.