Pull to refresh

Comments 31

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

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

дальше можно без зазрения совести использовать «пул реквест».
Если хочется перевести, я бы перевел «запрос на включение изменений». У меня лично «извлечение» почему-то вызывает ассоциации с хирургическим вмешательством.
Спасибо, ваш вариант мне нравится, хотя он и дальше от прямого перевода слова pull. Исправил в статье.
У нас в команде принят термин затягивание/вытягивание. И в некоторых локализованных программах так же.
Запрос на внесение, скорее уж.
Кстати, pull request — это не единственный способ обратить внимание разработчика на сделанные тобой изменения. Если изменение — это bugfix и спокойно укладывается в один коммит, то возможно, более логичным будет создать отчет об ошибке (в раздел issues) и включить в описание ошибки ссылку на коммит, который ее исправляет.

Ссылку на коммит в теле сообщения специально оформлять не нужно, достаточно просто включить в текст его идентификатор. Парсер markdown распознает его, сократит и преобразует в правильную ссылку.
Issues и Pull Requests на GitHub'е идут общим потоком (у них единая нумерация)… Есть ли смысл? К тому же как потом разработчику стягивать эти изменения? Простынёй команд вида origin add, fetch, cherry-pick?
К тому же, у pull request'ов есть киллер фича — зелёная кнопочка auto merge. Мэйнтэйнеру проще влить изменения, просто нажав на эту кнопочку :) (это, конечно, при условии, что нет конфликтов)
Спасибо за перевод. Использую git всего месяца 3. Когда начинал изучать тему, было немного сложновато разобраться.
Git — гениальное изобретение. Пробовал использовать 1-ю модель совместной работы, немного запутанно и не всегда merge проходит гладко, так что теперь использую 2 модель.
Тут не хватает только краткой информации о тегах.
А вообще я думаю полезная статья для начинающих гиттеров :)
При активной разработке гладко проходящие мёржи — редкость и счастье. 2-я модель подходит только в случае, когда трудятся пара-тройка человек, иначе, думаю, начнётся хаос и кто-нибудь обязательно набедокурит в общем репозитории.
Думаю, подробное описание тегов и веток (бранчей) — это уже за рамками этой статьи и само по себе немаленький разговор.
Я сделал форк, внёс изменения и запросил слияние 4 месяца назад…
Вопрос: почему на мой запрос никто не отвечает… что не так?
Я даже видео снял (в комменте ссылка) с демонстрацией исправлений…
Ссылка: https://qt.gitorious.org/qt/qt/merge_requests/1184

Буду рад если проясните мне моё положение…
1. Если это ещё не исправлено — ребейзлайн на текущую голову и новый запрос на пулл.
2. Если в течение недели не отвечают — пинг. Когда ответят — см. п.1.
Это безответственность разработчиков Qt — никак не прореагировать на запрос.
Они должны были как-то на него прореагировать: принять, отклонить или потребовать дополнений.
Найдите способ как-то с ними связаться (в списке рассылки, IRC, Jabber) и обратите внимание на своё исправление явно.
Так же, возможно, вы не включили в запрос юнит-тесты или что-нибудь ещё, это где-то должно быть оговорено.
Спасибо за ответ, это мой первый вклад в оупенсурс.
Потому я был склонен думать, что сделал что-то не так…
Не туда, не то и не так отправил… Но раз вы говорите, попробую в IRC пообщаться…
Вклад в опенсурс — это очень здорово. Дерзайте. Я сам иногда балуюсь кодингом на Qt, так что я за вас всеми конечностями ))
Кстати в GitExtensions уже встроена работа с GitHub, и поиск проект и форк и все.
Кто-нибудь может мне подсказать, как делать pull request не в мастер, а в другую ветку?
Исправьте в статье, перед тем как сделать

git push origin feature

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

git add myfile.c
git commit -m 'Fix myfile.c'
У вас ссылки на две картинки побились: Кнопка «Fork» и Событие закрытия пулл реквеста. А так: спасибо за статью.
После переезда Хабра на новый движок во многих старых статьях ссылки побились. Раньше тут все нормально было.
Всегда ли после принятия pull request нужно удалять ветку относящуюся к нему?
Я не стал удалять ветку, сделал в нее еще коммит, но кнопки «Pull Request» на сайте не появилось.
Можно удалять, можно нет, на ваше усмотрение.
Когда pull request принят или закрыт, добавление коммитов в ветку уже ни на что не влияет. Но можно создать новый pull request из этой ветки, в него будут включены коммиты, не вошедшие в первый.
Возможно вы не слили в свою ветку 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

Я не эксперт в гит. Тут написал, как бы сделал сам, оказавшись в вашей ситуации. Никакого вреда то что тут написано принести не может (осторожно, перед удалением веток убедитесь, что вы создали ветку-копию). Но, думаю, вашу проблему должно решить.
Такой вопрос, могу ли я забрать некоторые коммиты из форка своего репозитория если владелец форка не присылал мене pull request? Если да то как?
Способов множество, выбирайте любой:
  1. Добавляете форк в свой репозиторий как 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
  2. Ещё можно прибавить к URLу коммита на гитхабе расширение .patch и полученный файл можно скормить команде git am, если мне память не изменяет.
Все картинки умерли, без них статья слабоактуальна
Изображения «полетели» к сожалению. Видимо дропнут либо почищен аккаунт на Evernote, где они хостились.
Only those users with full accounts are able to leave comments. Log in, please.