Envek 10 авг 2011 в 09:43

Pull request'ы на GitHub или Как мне внести изменения в чужой проект

6 мин

494K

Git*

Туториал

+76

Комментарии 31

ognevsky 10 авг 2011 в 10:50

Итак, что же такое «запрос на извлечение (сделанных вами изменений)» (именно так я перевёл pull request)?

Вы прикалываетесь? o_O Pull Request — это и в Африке Pull Request, какой еще запрос за извлечение? o_O

Envek 10 авг 2011 в 11:06

Честно говоря, до того, как сегодня утром я сел за написание этой статьи, я и сам не задумывался о переводе (вообще о возможности перевода) такого интуитивного термина. Дальше я и ссылаюсь только как «pull request» или «пулл реквест», но хотя бы один раз надо было написать, как же это по русски. И над переводом пришлось подумать… Да и в других местах я заходил в тупик, как то project maintainer и вообще, push, pull, fork, branch. Как это внятно перевести на русский, чтоб было понятно и читалось — не ясно.
У вас есть перевод лучше? Я с радостью его приму.

ognevsky 10 авг 2011 в 11:15

Я же выше написал: зачем переводить такие вещи?

-1

pelenka 10 авг 2011 в 11:20

автор правильно сделал, что в начале статьи пояснил перевод.

точно так же как википедия поясняет происхождение самых простых слов, например:
Програ́мма — (от греч. προ — пред, греч. γράμμα — запись)

дальше можно без зазрения совести использовать «пул реквест».

Outspector 10 авг 2011 в 11:32

Если хочется перевести, я бы перевел «запрос на включение изменений». У меня лично «извлечение» почему-то вызывает ассоциации с хирургическим вмешательством.

Envek 10 авг 2011 в 12:57

Спасибо, ваш вариант мне нравится, хотя он и дальше от прямого перевода слова pull. Исправил в статье.

cblp 10 авг 2011 в 11:32

У нас в команде принят термин затягивание/вытягивание. И в некоторых локализованных программах так же.

akzhan 10 авг 2011 в 12:56

Запрос на внесение, скорее уж.

Outspector 10 авг 2011 в 11:24

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

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

Envek 10 авг 2011 в 14:27

Issues и Pull Requests на GitHub'е идут общим потоком (у них единая нумерация)… Есть ли смысл? К тому же как потом разработчику стягивать эти изменения? Простынёй команд вида origin add, fetch, cherry-pick?
К тому же, у pull request'ов есть киллер фича — зелёная кнопочка auto merge. Мэйнтэйнеру проще влить изменения, просто нажав на эту кнопочку :) (это, конечно, при условии, что нет конфликтов)

Pedectrian 10 авг 2011 в 14:11

Спасибо за перевод. Использую git всего месяца 3. Когда начинал изучать тему, было немного сложновато разобраться.
Git — гениальное изобретение. Пробовал использовать 1-ю модель совместной работы, немного запутанно и не всегда merge проходит гладко, так что теперь использую 2 модель.
Тут не хватает только краткой информации о тегах.
А вообще я думаю полезная статья для начинающих гиттеров :)

jcmvbkbc 10 авг 2011 в 14:25

Начинающий гиттер, прочти вот это, особенно главу 8 и вот это. Остальное — в мануалах.

Envek 10 авг 2011 в 14:37

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

k06a 10 авг 2011 в 18:37

Я сделал форк, внёс изменения и запросил слияние 4 месяца назад…
Вопрос: почему на мой запрос никто не отвечает… что не так?
Я даже видео снял (в комменте ссылка) с демонстрацией исправлений…
Ссылка: https://qt.gitorious.org/qt/qt/merge_requests/1184

Буду рад если проясните мне моё положение…

jcmvbkbc 10 авг 2011 в 20:12

1. Если это ещё не исправлено — ребейзлайн на текущую голову и новый запрос на пулл.
2. Если в течение недели не отвечают — пинг. Когда ответят — см. п.1.

Envek 10 авг 2011 в 23:59

Это безответственность разработчиков Qt — никак не прореагировать на запрос.
Они должны были как-то на него прореагировать: принять, отклонить или потребовать дополнений.
Найдите способ как-то с ними связаться (в списке рассылки, IRC, Jabber) и обратите внимание на своё исправление явно.
Так же, возможно, вы не включили в запрос юнит-тесты или что-нибудь ещё, это где-то должно быть оговорено.

k06a 12 авг 2011 в 20:30

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

Envek 13 авг 2011 в 10:25

Вклад в опенсурс — это очень здорово. Дерзайте. Я сам иногда балуюсь кодингом на Qt, так что я за вас всеми конечностями ))

AlexeiKozlov 18 авг 2011 в 19:18

Кстати в GitExtensions уже встроена работа с GitHub, и поиск проект и форк и все.

ulu 29 янв 2012 в 17:49

Кто-нибудь может мне подсказать, как делать pull request не в мастер, а в другую ветку?

ulu 29 янв 2012 в 18:10

Отмена, разобрался.

Sleuthhound 15 ноя 2013 в 06:26

Исправьте в статье, перед тем как сделать

git push origin feature

нужно добавить файлы в которых мы что то меняли и сделать комит:

git add myfile.c
git commit -m 'Fix myfile.c'

ulysses 3 сен 2014 в 09:00

У вас ссылки на две картинки побились: Кнопка «Fork» и Событие закрытия пулл реквеста. А так: спасибо за статью.

rotor 3 сен 2014 в 20:23

После переезда Хабра на новый движок во многих старых статьях ссылки побились. Раньше тут все нормально было.

Azimuth 9 мар 2015 в 14:43

Всегда ли после принятия pull request нужно удалять ветку относящуюся к нему?
Я не стал удалять ветку, сделал в нее еще коммит, но кнопки «Pull Request» на сайте не появилось.

Envek 9 мар 2015 в 19:41

Можно удалять, можно нет, на ваше усмотрение.
Когда pull request принят или закрыт, добавление коммитов в ветку уже ни на что не влияет. Но можно создать новый pull request из этой ветки, в него будут включены коммиты, не вошедшие в первый.

rotor 10 мар 2015 в 18:19

Возможно вы не слили в свою ветку upstream/master (в терминах этой статьи) поэтому ГитХаб не может определить.
После того, как ваш ПР приняли вам нужно было сделать что то вроде этого:

git checkout master
git fetch upstream
git pull upstream master
git checkout yourbranch
git merge master

И только потом делать новые коммиты в yourbranch.
Но сейчас, поскольку коммиты уже сделаны, то можно попробовать сделать так:

git checkout master
git fetch upstream
git pull upstream master
git checkout -b yourbranch1
git merge master
git merge yourbranch

Этим мы создали ветку yourbranch1 в которой ваш первый принятый ПР и ваши новые коммиты.
Затем, если вы хотите сохранить имя старой ветки, то вам придется ее пересоздать:

git branch -d yourbranch #Удаляем в локальном репозитории
git push origin :yourbranch #Удаляем в удалённом репозитории

Затем переименовываем yourbranch1 в yourbranch:

git checkout yourbranch1
git checkout -b yourbranch    #Вновь создаем yourbranch как копию yourbranch1
git checkout -d yourbranch1   #Удаляем yourbranch1

Все теперь можно пушить yourbranch:

git push origin yourbranch

Я не эксперт в гит. Тут написал, как бы сделал сам, оказавшись в вашей ситуации. Никакого вреда то что тут написано принести не может (осторожно, перед удалением веток убедитесь, что вы создали ветку-копию). Но, думаю, вашу проблему должно решить.

Hoshi 29 мая 2015 в 00:31

Такой вопрос, могу ли я забрать некоторые коммиты из форка своего репозитория если владелец форка не присылал мене pull request? Если да то как?

Envek 29 мая 2015 в 08:10

Способов множество, выбирайте любой:

Добавляете форк в свой репозиторий как remote:
```
git remote add FORKNAME git@github.com:AUTHOR/REPO.git
```
и далее стягиваете его изменения к себе в локальную копию
```
git fetch FORKNAME
```
1. и либо мёрджите себе его ветку
```
git merge FORKNAME/BRANCH
```
2. либо отбираете отдельные коммиты
```
git cherry-pick COMMIT_1_SHA COMMIT_2_SHA
```
Ещё можно прибавить к URLу коммита на гитхабе расширение .patch и полученный файл можно скормить команде git am, если мне память не изменяет.