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

[ognevsky]

Итак, что же такое «запрос на извлечение (сделанных вами изменений)» (именно так я перевёл pull request)?Вы прикалываетесь? o_O Pull Request — это и в Африке Pull Request, какой еще запрос за извлечение? o_O

[Envek]

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

[ognevsky]

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

[pelenka]

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

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

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

[Outspector]

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

[Envek]

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

[cblp]

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

[akzhan]

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

[Outspector]

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

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

[Envek]

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

[Pedectrian]

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

[jcmvbkbc]

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

[Envek]

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

[k06a]

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

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

[jcmvbkbc]

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

[Envek]

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

[k06a]

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

[Envek]

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

[AlexeiKozlov]

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

[ulu]

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

[ulu]

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

[Sleuthhound]

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

git push origin feature

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

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

[ulysses]

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

[rotor]

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

[Azimuth]

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

[Envek]

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

[rotor]

Возможно вы не слили в свою ветку 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]

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

[Envek]

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

1. Добавляете форк в свой репозиторий как remote:

   git remote add FORKNAME [e-mail]:AUTHOR/REPO.git
   

   и далее стягиваете его изменения к себе в локальную копию

   git fetch FORKNAME

   1. и либо мёрджите себе его ветку

      git merge FORKNAME/BRANCH

   2. либо отбираете отдельные коммиты

      git cherry-pick COMMIT_1_SHA COMMIT_2_SHA

2. Ещё можно прибавить к URLу коммита на гитхабе расширение .patch и полученный файл можно скормить команде git am, если мне память не изменяет.

[makarenya]

Все картинки умерли, без них статья слабоактуальна

[pprometey]

Изображения «полетели» к сожалению. Видимо дропнут либо почищен аккаунт на Evernote, где они хостились.

[iasonov]

+1 коммент про умершие изображения