Comments 31
Итак, что же такое «запрос на извлечение (сделанных вами изменений)» (именно так я перевёл pull request)?Вы прикалываетесь? o_O Pull Request — это и в Африке Pull Request, какой еще запрос за извлечение? o_O
Честно говоря, до того, как сегодня утром я сел за написание этой статьи, я и сам не задумывался о переводе (вообще о возможности перевода) такого интуитивного термина. Дальше я и ссылаюсь только как «pull request» или «пулл реквест», но хотя бы один раз надо было написать, как же это по русски. И над переводом пришлось подумать… Да и в других местах я заходил в тупик, как то project maintainer и вообще, push, pull, fork, branch. Как это внятно перевести на русский, чтоб было понятно и читалось — не ясно.
У вас есть перевод лучше? Я с радостью его приму.
У вас есть перевод лучше? Я с радостью его приму.
У нас в команде принят термин затягивание/вытягивание. И в некоторых локализованных программах так же.
Запрос на внесение, скорее уж.
Кстати, pull request — это не единственный способ обратить внимание разработчика на сделанные тобой изменения. Если изменение — это bugfix и спокойно укладывается в один коммит, то возможно, более логичным будет создать отчет об ошибке (в раздел issues) и включить в описание ошибки ссылку на коммит, который ее исправляет.
Ссылку на коммит в теле сообщения специально оформлять не нужно, достаточно просто включить в текст его идентификатор. Парсер markdown распознает его, сократит и преобразует в правильную ссылку.
Ссылку на коммит в теле сообщения специально оформлять не нужно, достаточно просто включить в текст его идентификатор. Парсер markdown распознает его, сократит и преобразует в правильную ссылку.
Issues и Pull Requests на GitHub'е идут общим потоком (у них единая нумерация)… Есть ли смысл? К тому же как потом разработчику стягивать эти изменения? Простынёй команд вида origin add, fetch, cherry-pick?
К тому же, у pull request'ов есть киллер фича — зелёная кнопочка auto merge. Мэйнтэйнеру проще влить изменения, просто нажав на эту кнопочку :) (это, конечно, при условии, что нет конфликтов)
К тому же, у pull request'ов есть киллер фича — зелёная кнопочка auto merge. Мэйнтэйнеру проще влить изменения, просто нажав на эту кнопочку :) (это, конечно, при условии, что нет конфликтов)
Спасибо за перевод. Использую git всего месяца 3. Когда начинал изучать тему, было немного сложновато разобраться.
Git — гениальное изобретение. Пробовал использовать 1-ю модель совместной работы, немного запутанно и не всегда merge проходит гладко, так что теперь использую 2 модель.
Тут не хватает только краткой информации о тегах.
А вообще я думаю полезная статья для начинающих гиттеров :)
Git — гениальное изобретение. Пробовал использовать 1-ю модель совместной работы, немного запутанно и не всегда merge проходит гладко, так что теперь использую 2 модель.
Тут не хватает только краткой информации о тегах.
А вообще я думаю полезная статья для начинающих гиттеров :)
При активной разработке гладко проходящие мёржи — редкость и счастье. 2-я модель подходит только в случае, когда трудятся пара-тройка человек, иначе, думаю, начнётся хаос и кто-нибудь обязательно набедокурит в общем репозитории.
Думаю, подробное описание тегов и веток (бранчей) — это уже за рамками этой статьи и само по себе немаленький разговор.
Думаю, подробное описание тегов и веток (бранчей) — это уже за рамками этой статьи и само по себе немаленький разговор.
Я сделал форк, внёс изменения и запросил слияние 4 месяца назад…
Вопрос: почему на мой запрос никто не отвечает… что не так?
Я даже видео снял (в комменте ссылка) с демонстрацией исправлений…
Ссылка: https://qt.gitorious.org/qt/qt/merge_requests/1184
Буду рад если проясните мне моё положение…
Вопрос: почему на мой запрос никто не отвечает… что не так?
Я даже видео снял (в комменте ссылка) с демонстрацией исправлений…
Ссылка: https://qt.gitorious.org/qt/qt/merge_requests/1184
Буду рад если проясните мне моё положение…
1. Если это ещё не исправлено — ребейзлайн на текущую голову и новый запрос на пулл.
2. Если в течение недели не отвечают — пинг. Когда ответят — см. п.1.
2. Если в течение недели не отвечают — пинг. Когда ответят — см. п.1.
Это безответственность разработчиков Qt — никак не прореагировать на запрос.
Они должны были как-то на него прореагировать: принять, отклонить или потребовать дополнений.
Найдите способ как-то с ними связаться (в списке рассылки, IRC, Jabber) и обратите внимание на своё исправление явно.
Так же, возможно, вы не включили в запрос юнит-тесты или что-нибудь ещё, это где-то должно быть оговорено.
Они должны были как-то на него прореагировать: принять, отклонить или потребовать дополнений.
Найдите способ как-то с ними связаться (в списке рассылки, IRC, Jabber) и обратите внимание на своё исправление явно.
Так же, возможно, вы не включили в запрос юнит-тесты или что-нибудь ещё, это где-то должно быть оговорено.
Кстати в GitExtensions уже встроена работа с GitHub, и поиск проект и форк и все.
Кто-нибудь может мне подсказать, как делать pull request не в мастер, а в другую ветку?
Исправьте в статье, перед тем как сделать
git push origin feature
нужно добавить файлы в которых мы что то меняли и сделать комит:
git add myfile.c
git commit -m 'Fix myfile.c'
git push origin feature
нужно добавить файлы в которых мы что то меняли и сделать комит:
git add myfile.c
git commit -m 'Fix myfile.c'
У вас ссылки на две картинки побились: Кнопка «Fork» и Событие закрытия пулл реквеста. А так: спасибо за статью.
Всегда ли после принятия pull request нужно удалять ветку относящуюся к нему?
Я не стал удалять ветку, сделал в нее еще коммит, но кнопки «Pull Request» на сайте не появилось.
Я не стал удалять ветку, сделал в нее еще коммит, но кнопки «Pull Request» на сайте не появилось.
Можно удалять, можно нет, на ваше усмотрение.
Когда pull request принят или закрыт, добавление коммитов в ветку уже ни на что не влияет. Но можно создать новый pull request из этой ветки, в него будут включены коммиты, не вошедшие в первый.
Когда pull request принят или закрыт, добавление коммитов в ветку уже ни на что не влияет. Но можно создать новый pull request из этой ветки, в него будут включены коммиты, не вошедшие в первый.
Возможно вы не слили в свою ветку upstream/master (в терминах этой статьи) поэтому ГитХаб не может определить.
После того, как ваш ПР приняли вам нужно было сделать что то вроде этого:
И только потом делать новые коммиты в yourbranch.
Но сейчас, поскольку коммиты уже сделаны, то можно попробовать сделать так:
Этим мы создали ветку yourbranch1 в которой ваш первый принятый ПР и ваши новые коммиты.
Затем, если вы хотите сохранить имя старой ветки, то вам придется ее пересоздать:
Затем переименовываем yourbranch1 в yourbranch:
Все теперь можно пушить yourbranch:
Я не эксперт в гит. Тут написал, как бы сделал сам, оказавшись в вашей ситуации. Никакого вреда то что тут написано принести не может (осторожно, перед удалением веток убедитесь, что вы создали ветку-копию). Но, думаю, вашу проблему должно решить.
После того, как ваш ПР приняли вам нужно было сделать что то вроде этого:
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? Если да то как?
Способов множество, выбирайте любой:
- Добавляете форк в свой репозиторий как remote:
и далее стягиваете его изменения к себе в локальную копиюgit remote add FORKNAME git@github.com:AUTHOR/REPO.gitgit fetch FORKNAME- и либо мёрджите себе его ветку
git merge FORKNAME/BRANCH - либо отбираете отдельные коммиты
git cherry-pick COMMIT_1_SHA COMMIT_2_SHA
- и либо мёрджите себе его ветку
- Ещё можно прибавить к URLу коммита на гитхабе расширение
.patchи полученный файл можно скормить командеgit am, если мне память не изменяет.
Все картинки умерли, без них статья слабоактуальна
Изображения «полетели» к сожалению. Видимо дропнут либо почищен аккаунт на Evernote, где они хостились.
Sign up to leave a comment.
Pull request'ы на GitHub или Как мне внести изменения в чужой проект