Содержание

git — Что такое pull request?

1. Что такое pull request?

1. Определение

pull request — предложение изменения кода в чужом репозитории.

Вы делаете форк чужого репозитория (который иногда и сам может быть форком) → производите изменения в своём форке → посредством pull request предлагаете изменения владельцам репозитория, чей форк Вы сделали. На GitHub pull request в публичный репозиторий может осуществить любая/ой зарегистрированная/ый участница/участник.

2. Составляющие pull requests

  1. Изменения, которые собираетесь внести в чужой репозиторий,
  2. Описание этих изменений.

Рекомендации по грамотному внесению pull requests расписаны в ответе ув-мого IonDen.

3. Разновидности pull requests

Все pull requests можно разделить на следующие категории:

  1. Исправление багов, ошибок, конфликтов с другими приложениями,
  2. Добавление новых функций, возможностей,
  3. Рефакторинг, стилевые правки.
    Если владелица/владелец репозитория не значительно хуже Вас разбирается в коде репозитория, лучше не злоупотреблять pull requests данной категории.

4. Дополнительная ссылка


2. Как сделать и принять pull request при помощи hub

1. Что такое hub?

hub — консольное приложение, упрощающее введение команд git, обёртка для git. Например, чтобы клонировать репозиторий, используя git, мы должны ввести в терминал:

git clone https://github.com/Kristinita/SashaSublime.git

В hub команда выглядит проще:

hub clone Kristinita/SashaSublime

Полный список команд hub, и что они упрощают, см. в документации hub.

На момент написания ответа (ноябрь 2016) hub работает

только с GitHub, но не BitBucket или прочими ресурсами для хранения кода. Для пользователей Windows доступна установка через пакетный менеджер Chocolatey — cinst hub -y.

2. Зачем использовать hub?

Фиксить мелкие баги и опечатки, а затем сделать pull-request проще через веб-интерфейс GitHub. Однако если Ваши изменения довольно значительны, лучше клонировать репозиторий к себе на компьютер по следующим причинам:

  • IDE/продвинутые текстовые редакторы предоставляют значительно больше возможностей для работы с кодом в сравнении с редактированием в вебе;
  • Могут понадобиться разного рода тесты, недоступные при редактировании в веб-интерфейсе;
  • Для многих предпочтительнее работать в терминале.

Итак, вы решили клонировать репозиторий. hub упрощает:

  • Клонирование удалённого репозитория; рассмотрено в п. 2.1 данного ответа;
  • Форк; достаточно ввести в терминал hub fork;
  • pull request; после того, как Вы запушили изменения в свой форк, достаточно ввести в терминал hub pull-request.

3. Настройка hub перед использованием

  1. Создайте пользовательскую переменную среды GIT_EDITOR
    , — это сделать просто при помощи Rapid Environment Editor, — значением для которой будет путь к исполняемому файлу Вашего редактора, в котором Вам удобно писать pull request message, — описание Вашего pull request, — при необходимости добавив аргументы командной строки. Например, у меня для Sublime Text значение вышло следующим:
"D:\Sublime Text 3 x64\sublime_text.exe" -n -w

Если путь к исполняемому файлу содержит пробелы,

во избежание багов, лучше заключить его в кавычки.

  1. При использовании hub в Windows и открытии редактируемых файлов в Sublime Text могут возникнуть проблемы с pull requests от имени администратора. Поскольку это не первая моя проблема, связанная с UAC, а толку от него не вижу, я отключил у себя контроль учётных записей.
  2. Комментарии — текст под сообщением во вкладке PULLREQ_EDITMSG — по умолчанию выделяются #октоторпами#. Но когда Вы внесёте pull request в чужой репозиторий, то обнаружите, что текст под сообщением отобразится как заголовки, а не комментарии.

Необходима настройка git. Введите в терминал команду:

git config --global core. commentChar %

Отныне комментариям во вкладке PULLREQ_EDITMSG будут предшествовать символы %процента%, после внесения pull request комментариев не будет видно как визуально, так и в исходном коде описания к pull request.

При необходимости резервных копий или синхронизации пользовательской конфигурации файлов git узнать, где хранятся конфигурационные файлы git, начиная с версии 2.8 можно командой:

git config --list --show-origin

Например, у меня в Windows 10 путь к файлу, где хранится данная настройка для комментариев, оказался следующим:

file:C:/Users/SashaChernykh/.gitconfig  core.commentchar=%

Если Ваша проблема отлична от расписанных здесь, и её разрешения не получается найти поисками Google и по репозиторию; попробуйте ещё раз воспроизвести проблему, перед введением команд hub послав в терминал следующую команду:

set HUB_VERBOSE=1

В терминале появится отладочная информация. Если и по ней не получилось разрешить проблему, создайте багрепорт в issue tracker hub, приложив к сообщению вывод Вашего терминала вместе с отладочной информацией.

4. Пример создания pull request через hub

Сделаем посредством PowerShell и hub pull request в репозиторий https://github.com/LightAlf/bioRepo1. Помимо вышеперечисленных команд hub в примере используются также команды git, о предназначении которых можно узнать, например, из данного или этого ресурсов на русском.

PS E:\> hub clone LightAlf/bioRepo1
Cloning into 'bioRepo1'...
remote: Counting objects: 16, done.
remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16
Unpacking objects: 100% (16/16), done.
PS E:\> cd bioRepo1
PS E:\bioRepo1> Invoke-Item README.MD
# В Вашем редакторе открывается файл README.MD → вносите в него изменения → сохраняете файл.
PS E:\bioRepo1> git add .
PS E:\bioRepo1> git commit -m "Тестирование pull-request посредством hub"
[master 839c146] Тестирование pull-request посредством hub
 1 file changed, 2 insertions(+)
PS E:\bioRepo1> hub fork
Updating Kristinita
From https://github.
com/LightAlf/bioRepo1 * [new branch] discuss -> Kristinita/discuss * [new branch] master -> Kristinita/master new remote: Kristinita PS E:\bioRepo1> git checkout -b SashaGoddess Switched to a new branch 'SashaGoddess' PS E:\bioRepo1> git push Kristinita SashaGoddess Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 471 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/Kristinita/bioRepo1.git * [new branch] SashaGoddess -> SashaGoddess PS E:\bioRepo1> hub pull-request # Откроется вкладка с файлом PULLREQ_EDITMSG, как на картинке ниже → вписываете в него изменения → сохраняете файл → закрываете его. https://github.com/LightAlf/bioRepo1/pull/2 PS E:\bioRepo1>

Результат:

5. Пример принятия pull-request при помощи hub

Если pull request предложен Вам, Вы можете принять его из терминала, воспользовавшись командой hub — hub merge. Изменения будут влиты в Ваш локальный репозиторий; чтобы перенести их на удалённый, следует сделать git push. Пример, как принять pull-request. если ветка, в которую предложили сделать pull request, является веткой по умолчанию.

[email protected] MINGW32 /e/SashaChocolatey (master)
# Где E:\SashaChocolatey — локальный репозиторий, в связанный с которым удалённый репозиторий был внесён pull-request
$ hub merge https://github.com/Kristinita/SashaChocolatey/pull/1
# Где https://github.com/Kristinita/SashaChocolatey/pull/1 — ссылка на pull-request
Merge made by the 'recursive' strategy.
 packages/Karens Replicator/tools/chocolateyinstall.ps1 | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

[email protected] MINGW32 /e/SashaChocolatey (master)
$ hub push
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (15/15), 1.56 KiB | 0 bytes/s, done.
Total 15 (delta 8), reused 0 (delta 0) remote: Resolving deltas: 100% (8/8), completed with 3 local objects. To https://github.com/Kristinita/SashaChocolatey.git 79ebe12..5045130 master -> master

Результат:

В описании коммита по умолчанию будут ссылки на коммит, которым приниматеся pull request, и на сам pull request, а также его заголовок.

Пользовательница/пользователь GitHub, у которой/которого Вы приняли pull request, не сразу, но будет указана/указан в числе контрибьюторов Вашего репозитория.


3. Дополнительная ссылка

git — Зачем нужен pull request, если есть push?

Организация работы, основанная на пулл-реквестах (pull-request, merge-request, запрос на слияние), характерна для распредленных проектов, которые размещаются на специальных хостингах репозиториев. Git сам по себе не имеет такого функционала, он реализуется именно хостингом. Кроме GitHub эту возможность предоставляет Gitlab, возможно есть и другие хостинги. Называется такая организация GitHub flow или Gitlab flow — в противоположность более традиционному Git flow git-flow («flow» — поток).

Про организацию Git flow можно почитать в описании метки. Кратко: есть основная ветка master, разработчики создают ветки под конкретные задачи (фича, багфикс), потом сливают их в master. Возможно использование ветки-агрегатора develop, в которой копятся изменения до момента очередного релиза.

Git flow реализуем, когда у всех разработчиков есть право создавать новые ветки в удалённом репозитории. Это часто так при закрытой разработке внутри компании, но почти всегда не так, когда проект хостится открыто. Нельзя просто так взять и запушить свою ветку в чужой репозиторий на GitHub.

Другое важное право — сливать изменения в ветку master или другую, из которой код уходит в производство. В открытом репозитории это может делать владелец или группа уполномоченных пользователей. В закрытом код обычно может сливать ответственный за это сотрудник. Перед слиянием код может и должен проходить инспекцию и тестироваться. Если у вас не так — повод обеспокоиться.

Чтобы у разработчиков всё-таки была возможность принимать участие, коммитить свои изменения/дополнения и потом предлагать слить их в основную ветку проекта, были придуманы форки (fork, вилка). Форк — это ваша собственная копия целого репозитория Git. В ней вы можете создавать собственные ветки, делать новые коммиты и всё остальное, что можно делать с принадлежащим вам репозиторием.

Чтобы предложить добавить ваши изменения в основной репозиторий, используется пулл-реквест. Алгоритм создания такой:

  1. Создаете локальную ветку. Создаете в ней новые коммиты (иначе нет смысла в слиянии).
  2. Пушите эту локальную ветку на удаленный репозиторий.
  3. Заходите на сайт хостинга репозиториев. Там выбираете одну из веток вашего удаленного репозитория и предлагаете влить её в одну из веток другого удалённого репозитория. Как вариант, если у вас есть право создавать ветки, но нет права сливать в master — можно создавать пулл-реквест внутри одного репозитория.
  4. Нажимаете кнопку подтверждения.

Теперь создаётся собственно пулл-реквест, как сущность. У него в том числе есть:

  • Номер и url. Он также появляется в списке открытых реквестов целевого репозитория.
  • Информация о внесённых изменениях в формате diff. Красным подсвечиваются удалённые строки, зелёным добавленные. Есть общая статистика добавленных и удаленных строк.

  • Возможность оставлять комментарии к любой строке диффа, а также к пулл-реквесту в целом. Эта невероятно полезная возможность позволяет проводить инспекцию кода прямо в пулл-реквесте.

  • Информация о новых коммитах в виде дерева.

  • Автоматическая оценка возможности бесконфликтного слияния. Если оно невозможно, придётся вручную разрешать конфликты, как в обычном слиянии.

  • Кнопки, чтобы слить или, наоборот, отклонить запрос.

Изучив ваш пулл-реквест, владелец основного репозитория может выполнить его слияние (а может и нет). Отсюда и название: не вы «выталкиваете» (push) свои изменения в чужой репозитория, а уполномоченный пользователь их «затаскивает» (pull) в него.

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

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub’а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request’ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Немного о моделях совместной разработки

На GitHub популярны две модели совместной разработки:
  1. Модель «Fork + Pull» позволяет любому склонировать (fork) существующий репозиторий и сливать изменения в свой личный fork без необходимости иметь доступ к оригинальному репозиторию. Затем, изменения должны быть включены в исходный репозиторий его хозяином. Эта модель уменьшает количество телодвижений для новых contributors и популярна для open source проектов, так как позволяет людям работать независимо, без единого координирования.
  2. Модель «общего репозитория» (The Shared Repository Model) чаще встречается у малых команд и организаций, работающих над закрытыми проектами. Каждый в команде имеет доступ «на запись» в один общий репозиторий, а для изолирования изменений применяются тематические ветви (topic branches).

Pull request’ы особенно полезны в модели «Fork + Pull», поскольку предоставляют способ уведомить мэйнтэйнеров проекта (т.е. хозяина оригинального репозитория) о изменениях в вашей копии репозитория. Впрочем, они так же полезны и в модели общего репозитория, где обычно используются для того, чтобы инициировать пересмотр или обсуждение кода перед тем, как включать его в основную ветвь разработки.
Делаем копию репозитория

Рассматривая первую модель разработки, необходимо иметь свою копию изначального репозитория, в которой и будет вестись работа, и изменения из которой и будут предлагаться затем автору изначального репозитория.

В рамках руководства, будем считать, что мы работаем над репозиторием Spoon-Knife пользователя octocat, а ваше имя пользователя — username.

Сделать это очень просто: на странице репозитория имеется кнопочка «Fork», которую и следует нажать.

После чего, эту свою копию уже можно «стянуть» на свой компьютер:

git clone [email protected] com:username/Spoon-Knife.git

Склонированный репозиторий имеет одну привязку к удалённому репозиторию, названную origin, которая указывает на вашу копию на GitHub, а не на оригинальный репозиторий, чтобы отслеживать изменения и в нём, вам нужно будет добавить другую привязку, названную, например, upstream.

cd Spoon-Knife
git remote add upstream git://github.com/octocat/Spoon-Knife.git
git fetch upstream
Делаем работу

Итак, в этой точке мы уже можем править код и делать коммиты. Если вы сделали все предыдущие шаги, чтобы потом вернуть ваши изменения в оригинальный репозиторий, то я настоятельно советую делать всю работу в отдельной тематической ветви разработки. Полезность этого станет ясна на этапе посылки pull request’а. Пускай она будет называться feature.
git checkout -b feature #Создаёт новую ветвь, названную "feature" и делает её активной

Вот, теперь творите добро (и пусть оно будет выражаться в коммитах).

Как только вы сделали работу (или её часть), отправьте её в свою копию репозитория на GitHub:

git push origin feature #Загружает изменения в текущей ветви в origin в ветвь feature
Возвращаем изменения: Pull request

Итак, всё сделано. Вы написали код, он у вас в ветви feature как у вас на компьютере, так и на GitHub’е. Осталось только «заслать» его в оригинальный репозиторий.

Идите на страницу вашей копии репозитория на GitHub, выбирайте ветвь feature и жмите кнопку Pull Request.

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

Там же вы можете посмотреть, какие коммиты попали в пулл реквест:

А так же общий diff всех изменений в пулл реквесте:

По умолчанию, пулл реквесты считаются основанными на самой часто интегрируемой ветви родительского репозитория. В этом случае username/Spoon-Knife был скопирован с octocat/Spoon-Knife, так что pull request считается основанным на ветке master репозитория octocat/Spoon-Knife. В большинстве случаев, это будет корректно, но если не так, то вы можете нажать на кнопку «Change Commits»

Вы попадёте в форму выбора базовой и исходной ветвей:

Слева выбираете в какую ветку будут вливаться изменения в родительском репозитории, справа — какие изменения будут браться с вашего репозитория. По примеру: справа octocat/Spoon-Knife/master, слева username/Spoon-Knife/feature. Здесь вы можете указывать не только ветки, но так же теги и id отдельных коммитов в соответствующем репозитории.
ВАЖНО: Договоритесь с владельцем «родительского» репозитория, в какую ветку будете вливать изменения (он может написать это в README)

Изменение базового репозитория меняет и список людей, кто получит уведомление о пулл реквесте. Каждый, кто имеет право «на запись» в базовый репозиторий, получит письмо и увидит уведомление на главной GitHub’а, в следующий раз, как на него зайдёт.
Как только список коммитов вас удовлетворит, нажмите кнопку Update Commit Range.

Когда вы ввели название и описание и перепроверили список коммитов и изменения в файлы, попавшие в пулл реквест, нажмите кнопку Send pull request. Пулл реквест будет создан незамедлительно.

Что дальше?

Следите за вашим пулл-реквестом. Что прокомментируют люди, что скажет мэйнтэйнер, примет или нет ваш пулл реквест.

Помните, я говорил, что следует все изменения, которые пойдут в пулл, держать в отдельной ветке? Так вот, основное удобство: вы всегда можете добавить коммиты к уже существующему пулл реквесту, просто добавив их к этой ветке в вашем репозитории (да-да, просто git push origin feature, при условии, что вы указали в пулл реквесте feature как исходную ветвь)

При просмотре пулл реквеста, кроме названия, описания и коммитов, так же отображаются:

  • Комментарии, оставленные к пулл реквесту;
  • Дополнительные коммиты, добавленные к ветви пулл реквеста;
  • Комментарии к изменённым строкам или файлам, оставленные к любому из коммитов, включенных в пулл реквест.

В комментариях к пулл реквесту можно использовать Markdown, то есть можно вставлять изображения и использовать всё форматирование, поддерживаемое Markdown.

Когда ваш pull request примут, не забудьте слить изменения в свой репозиторий (или удалить его, если больше не нужен):

git checkout master
git pull upstream master
git push origin master

Так же можно удалить ветку, в которой велась разработка:
git branch -d feature #В локальном репозитории
git push origin :feature #В удалённом репозитории
Что следует делать, если работа заняла большое время и оригинальный репозиторий успел уйти вперёд?

Можно просто влить изменения из оригинального репозитория к себе:
git checkout master
git pull upstream master
git checkout feature
git merge master

Однако хозяину оригинального репозитория или, может быть, даже вам, не понравится наличие мёрж-коммитов и коммитов из master’а в списке коммитов на пулл. В таком случае вам стоит воспользоваться git rebase.

git checkout master
git pull upstream master
git checkout feature
git rebase master #Всё отличие только здесь

Прочитать про то, как работает rebase можно в официальном руководстве. Там имеются и очень понятные иллюстрации. Так же есть статья в помощи GitHub.
ВНИМАНИЕ: Пожалуйста, учтите, что git rebase меняет id коммитов! Поэтому, все действия с этой командой стоит выполнять только на локальном репозитории, до того, как эти коммиты станут общедоступны, т.е. до того, как вы их push’нули на гитхаб.

Если вы хозяин: Как принять pull request

Если пулл реквест удовлетворяет всем условиям, то кто-либо с правом «на запись» (т.е. может сделать push) в целевой репозиторий, должен принять pull request одним из многих методов. Ниже описаны три наиболее популярных метода:
Auto Merge (автослияние)

Во многих случаях можно попросить github автоматически принять пулл реквест, используя большую зелёную кнопку Merge Pull Request, которая сама вольёт изменения, создаст мёрж-коммит и закроет пулл реквест.

Подробнее можно почитать в этом хабратопике: Кнопка слияния на GitHub.
Fetch and Merge (скачать и слить)

Основной метод вливания изменений. Он требует добавления remote, ведущего к репозиторию человека, отправившего pull request, скачивания изменений с этого репозитория, объединения нужной ветви, исправления конфликтов и выгрузки обновлённой ветви обратно в исходный репозиторий:
git checkout master
git remote add username git://github.com/username/Spoon-Knife.git
git fetch username
git merge username/feature
git push origin master
Patch and Apply (пропатчить и принять)

Предыдущий метод работает хорошо, когда вы работаете в команде или постоянно принимаете изменения от одной и той же группы людей. Другой метод немного быстрее в единичных случаях при использовании git-am.

У каждого пулл реквеста есть свой .patch URL, с которого можно скачать текстовый патч, чтобы скормить его команде git-am:

git checkout master
curl https://github. com/octocat/Spoon-Knife/pull/50.patch | git am
git push origin master
Закрытие пулл реквеста

Запросы на пулл автоматически закрываются, когда запрошенные коммиты вливаются в репозиторий назначения. При этом генерируется событие, информирующее всех участников разработки, что пулл реквест был принят и влит в основную ветвь.

Так же возможно вручную закрыть пулл реквест в случае, если он был отклонён. Иногда это необходимо в случаях, когда изменения были приняты с помощью git-cherry-pick или другого механизма, который не позволяет обнаружить факт слияния (merge).
Вместо заключения

Надеюсь, это руководство поможет вам в улучшении многих open-source (и не только) проектов.
Несмотря на большое время пребывания на Хабрахабре, это мой первый топик. Пожалуйста, сообщайте в личку или в комментариях обо всех недочётах, которые я мог допустить. Буду исправлять.
Большое спасибо Antiarchitect и другим хабраюзерам за помощь в опубликовании статьи, а так же, разумеется, команде разработчиков GitHub, за столь удобный и бесплатный для open-source сервис.

Как сделать первый пул-реквест на GitHub

Перевод статьи «How to make your first pull request on GitHub».

Что такое форк?

Когда нам нравится чей-то репозиторий и мы хотели бы иметь его в собственном аккаунте на GitHub, мы делаем форк («вилку») этого репозитория, чтобы иметь возможность работать с ним отдельно.

Когда мы делаем форк репозитория, мы получаем экземпляр всего репозитория, со всей его историей. После форка мы можем делать с ним все, что угодно: оригинальная версия при этом не будет задета.

Что такое пул-реквест?

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

Например, пользователь Павел делает форк репозитория ThanoshanMV (автора статьи, — прим. перев.) и вносит изменения в свой экземпляр. После этого Павел отсылает пул-реквест ThanoshanMV, который может либо принять его, либо отклонить. По сути это что-то вроде письма «Не будете ли вы так любезны, уважаемый ThanoshanMV, внести мои изменения в свой оригинальный репозиторий?»

Как можно стать контрибьютором проекта?

Участие в проекте с открытым исходным кодом не обязательно предполагает работу именно с кодом. Контрибьютором (участником) можно стать и другими способами, некоторые из них описаны ниже.

  1. Дизайн. Можно создать макеты проекта, чтобы повысить удобство его использования, усовершенствовать навигацию или меню, создать рисунки для лого или футболок, написать руководство по стилю проекта.
  2. Писательство. Можно написать документацию проекта или улучшить уже существующую, перевести документацию на свой язык, создать новостную рассылку для проекта, написать руководства для пользователей или заняться формированием папки с примерами использования.
  3. Организаторские задачи. Можно связывать дублирующиеся issues, предлагать новые метки для issues, предлагать закрытие старых, но еще открытых issues, задавать вопросы в новых — чтобы подстегивать развитие дискуссии.
  4. Помощь другим людям. Можно отвечать на вопросы в открытых issues, проверять код других разработчиков, предлагать помощь в качестве наставника.
  5. Написание кода. Можно помогать в решении возникших проблем, предлагать создание новых фич, а также улучшать инструментарий и тестирование.

Давайте создадим наш первый пул-реквест!

1. Форк репозитория

Чтобы сделать форк репозитория, нужно нажать кнопку «Fork» в верху страницы. Таким образом вы создадите экземпляр всего этого репозитория в своем аккаунте.

2. Клонирование репозитория

Когда репозиторий уже есть в вашем аккаунте, вы можете клонировать его на свою машину и в дальнейшем работать с ним локально.

Чтобы клонировать репозиторий, нажмите кнопку «clone» и скопируйте ссылку.

Откройте терминал и запустите следующую команду. С ее помощью репозиторий будет клонирован на вашу машину.

$ git clone [HTTPS ADDRESS]

Теперь у вас есть копия ветки master основного онлайн-репозитория проекта.

Переходим в клонированную директорию:

$ cd [NAME OF REPOSITORY]

3.

Создание ветки

При работе с репозиторием хорошей практикой считается создание отдельной ветки для внесения изменений, причем это не зависит от размеров проекта.

Имя ветки должно быть коротким и отражать те изменения, которые вы вносите.

Создадим ветку при помощи команды git checkout:

$ git checkout -b [Branch Name]

4. Внесение изменений и коммит

Внесите необходимы изменения в проект и сохраните их. Затем запустите команду git status: вы увидите внесенные изменения.

Добавьте эти изменения в только что созданную ветку при помощи команды git add:

$ git add .

Теперь вы можете сделать коммит этих изменений при помощи команды git commit:

$ git commit -m "Adding an article to week 02 of articles of the week"

5. Отправка изменений на GitHub

Чтобы отправить изменения на GitHub (сделать push), нужно определить имя удаленного репозитория.

$ git remote

Имя данного удаленного репозитория — «origin».

После определения имени можно безопасно отправить изменения на GitHub.

git push origin [Branch Name]

6. Создание пул-реквеста

Перейдите в свой репозиторий на GitHub. Там есть кнопка «Compare & pull request» — кликните ее.

Введите необходимые детали относительно того, что именно вы сделали (чтобы поставить ссылку на issues, возмользуйтесь знаком «решетки»). После этого можно нажать кнопку подтверждения внизу.

Поздравляю! Вы создали свой первый пул-реквест. Если его примут, вы получите уведомление по электронной почте.

7. Синхронизация вашего форка с основной веткой

Прежде чем создавать пул-реквест в оригинальный репозиторий, нужно синхронизировать свой экземпляр этого репозитория с оригинальным.

Даже если вы не собираетесь отправлять пул-реквест в оригинальный репозиторий, все равно лучше синхронизироваться с ним. Со времени создания форка в оригинальном репозитории могли добавиться новые фичи, а также могли быть исправлены какие-то баги.

Проделайте следующие действия, чтобы обновить свой репозиторий и внести соответствующие изменения в свою ветку master:

1. Для начала, проверьте, в какой ветке вы находитесь.
$ git branch

Вы получите список всех веток, причем активная будет подсвечена зеленым.

2. Переключитесь в ветку master.
$ git checkout master
3. Добавьте оригинальный репозиторий в качестве upstream-репозитория.

Чтобы вытащить изменения из оригинального репозитория и перенести их в свою версию, нужно добавить оригинальный git-репозиторий в качестве upstream-репозитория.

$ git remote add upstream [HTTPS]

Здесь [HTTPS] это url, который нужно скопировать из основного репозитория.

4. Fetch репозитория

Заберите (fetch) все изменения из оригинального репозитория. Коммиты, сделанные в оригинальном репозитории, будут сохранены в локальной ветке под названием upstream/master.

$ git fetch upstream
5. Слейте изменения

Слейте (merge) изменения из upstream/master с вашей локальной веткой master. Таким образом главная ветка вашего форка репозитория синхронизируется с upstream-репозиторием без потери ваших локальных изменений.

$ git merge upstream/master
6. Отправьте изменения на GitHub

На этом этапе ваша локальная ветка синхронизирована с веткой master оригинального репозитория. Если вы хотите обновить свой GitHub-репозиторий, нужно отправить в него изменения.

$ git push origin master

Примечание. После синхронизации ветки master вашего форка вы можете при желании удалить remote. Но в будущем вам еще придется обновлять/синхронизировать ваш репозиторий, поэтому лучше его сохранить.

$ git remote rm [Remote Name]

8. Удаление ненужной ветки

Ветки создаются с какими-то конкретными целями. Когда цель достигнута, необходимость в ветке отпадает, поэтому ее можно удалить.

$ git branch -d [Branch Name]

Вы можете удалить и версию этой ветки на GitHub.

git push origin --delete [Branch Name]

Итоги

GitHub это мощный инструмент для контроля истории версий. Каждый может стать контрибьютором проекта с открытым исходным кодом. Делается это путем отправки пул-реквестов.

Чтобы стать контрибьютором, не обязательно писать код: есть и другие способы принять участие в проекте.

Наконец, я хотел бы также сказать, что не стоит переживать, если ваши пул-реквесты отклонят. Мейнтейнеры тратят много времени на улучшение своих проектов и они, безусловно, лучше знают эти проекты, чем вы. Поэтому не стоит переживать, если они решат не вливать в свой проект ваши изменения.

Работа с git

В кругу моих знакомых имеются товарищи весьма и весьма далёкие от мира железок, интернета и open source (в общем, они пропустили всё самое интересное). Не далее как на прошлой неделе угораздило таки употребить при них непотребное словосочетание «pull request», после чего, ловя недоумённые взгляды, пришлось мяться и придумывать как сие получше перевести на великий и могучий. Увы, к взаимопониманию это не привело: попробую ответить здесь.

Pull Request — запрос на включение. На включение написанного вами кода в чужой репозиторий.

С чего начать?

А для начала этот самый репозиторий нужно форкнуть (fork — вилка, ответвление). Разберём это нехитрое действо на примере веб-сервиса для хостинга IT-проектов, название которому GitHub. Разумеется, кроме GitHub есть и другие: BitBucket, например. Выбирать по вкусу.

Примечание

Для успешного проведения нижеизложенных операций у вас (что естественно) должен быть установлен git

Заходим на страницу интересующего проекта, жмём кнопку Fork, ищем на своей странице URL для клонирования.

В консоли в зависимости от входных данных набираем нечто подобное:

$ git clone [email protected]/username/django_documentation.git

Отлично. Уже можно вносить свои изменения в код проекта.

Тот репозиторий, что теперь лежит на вашем жёстком диске, независим от основного. В нём отслеживаются только ваши наработки. Но как следить за изменениями, происходящими в первоисточнике, откуда вы «стянули» репозиторий? Добавить удаленный репозиторий в отслеживаемые. Например, так:

$ git remote -v
origin  [email protected]:username/django_documentation.git (fetch)
origin  [email protected]:username/django_documentation.git (push)

$ git remote add upstream [email protected]:Alerion/django_documentation.git

После добавления upstream в отслеживаемые, наберите команду git remote -v ещё раз, вы должны увидеть произошедшие изменения.

Давайте посмотрим как сливать изменения из оригинального репозитория к себе в случае, если разработка в нём ушла вперёд пока вы сосредоточенно писали коммиты:

$ git pull upstream master
From github.com:Alerion/django_documentation
* branch            master     -> FETCH_HEAD
Updating 66f032e..062b294
Fast-forward
djbook/commands/authors.py                    | 65 ++--
djbook/deps. txt                               |  6 ++--
djbook/templates/authors.html                 | 14 ++--
djbook/templates/base.html                    |  7 ++--
locale/ru/LC_MESSAGES/faq/install.po          | 94 +++-
locale/ru/LC_MESSAGES/faq/usage.po            | 49 +---
locale/ru/LC_MESSAGES/howto/outputting-csv.po | 61 ++--
locale/ru/LC_MESSAGES/topics/cache.po         | 77 ++--
locale/ru/LC_MESSAGES/topics/db/multi-db.po   | 80 +++-
9 files changed, 290 insertions(+), 163 deletions(-)

У нас есть основной репозиторий с веткой master и недавно добавленный нами — с upstream. Команда, данная выше, забирает всё новое из ветки upstream и сливает изменения в master. Так, мы всегда можем получить последние наработки.

Вы можете также воспользоваться другой командой — fetch вместо указанной pull. В таком случае git заберет изменения с удаленного репозитория, но не будет пытаться слить их с вашей текущей веткой автоматически.

$ git fetch upstream
$ git merge upstream/master

Допустим, мы написали, что хотели и сделали коммит. Забираем изменения (но не сливаем их, fetch) из upstream. Затем вручную сливаем изменения из удалённой ветки upstream/master к себе (merge), разрешаем конфликты (если есть) и снова делаем коммит.

Если репозиторий огромен, а забирать его весь не хочется, клонируем только нужную ветку:


$ git clone -b real_branch --single-branch [email protected]/username/django_documentation.git

Что такое ветки?

Чаще всего ветки (branch — ответвление, ветвь, филиал) бывают тематическими. Например, при общей разработке, когда у всех участников есть право записи в репозиторий. В этом случае ветки используются для отделения изменений, сделанных одним из разработчиков, от общего репозитория. Ветки могут пригодиться и в случае с созданием pull-request’а.

Создание ветки происходит довольно просто. Находясь в каталоге с проектом, наберите следующие команды:


$ git branch -a
* master
remotes/origin/1. 4
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/upstream/1.4
remotes/upstream/master


$ git checkout -b new_branch

Новые ветки создаются не только из master, берите любую!


$ git checkout -b new_branch origin/1.4


$ git checkout -t origin/1.4

Находясь в только что созданной ветке, вы можете приступить к работе. Вносите в код свои изменения, а когда закончите просто переключитесь обратно к своей основной ветке. Вы можете отправить pull request, выбрав ветку new_branch или же прежде слить изменения из неё в основную ветку разработки. Рассмотрим это подробнее:

$ git checkout master  
$ git merge new_branch 

Если нужно отправить в свой удалённый репозиторий вновь созданную ветку (не сливать её с master), делаем следующее:

$ git push master new_branch

Не торопитесь сливать изменения. Если что-то не заладилось, созданную ветку можно удалить:

$ git branch -d new_branch            
$ git push master :new_branch         


$ git push origin --delete new_branch

Удалить все локальные ветки, которые были смержены (то есть код которых теперь есть) в ветках develop или master:

$ git branch --merged | egrep -v "(master|develop)" | xargs git branch -d

Отправляем изменения

Добрались таки до ответа на поставленный вопрос: что такое pull request, зачем оно нужно и как его достичь. Как предложить владельцу репозитория свои изменения?

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

Перед тем как сделать запрос вы имеете возможность добавить комментарий, просмотреть то, какие файлы будут изменены, какие коммиты добавлены. В верхнем углу окна добавления запроса обратите внимание откуда куда и что вы сливаете. Если необходимо слить основные ветки выбор падёт на репозиторий username:master, если отдельную ветку (вспоминаем branch) — так и указывайте её.

А дальше… ждать. Пока придёт владелец оригинального репозитория и примет/отклонит ваши изменения.

Ну вот, мы его достигли. Просветления то есть 🙂

Как отменить изменения

Если что-то пошло совсем не так как хотелось, изменения можно «откатить». Когда изменённый файл ещё не проиндексирован, сделать это просто:

Когда нужно вернуть более старое состояние уже проиндексированных файлов и забыть о них совсем (помните, что упомянутая здесь операция отменит всю вашу работу до определённого коммита!):

$ git log
$ git reset --hard HEAD~1

Cмотрим на какой коммит откатиться. В примере откатываемся назад на 1 коммит. Для изменения состояния в этой же ветке удалённого репозитория тоже придётся использовать грубую силу — флаг force:

$ git push origin new_branch:new_branch --force

Охватить все варианты невозможно, поэтому рекомендуется обратиться к документации и найти команду git revert и ключ --soft. Отдельно хочется отметить: в git ничего не пропадает бесследно. Если файлы были удалены, их можно восстановить опять.

$ git checkout 4b9df4bbd -- files

Дословно можно понимать эту команду как «из коммита 4b9df4bbd вернуть files». Затем останется только зафиксировать изменения (сделать коммит).

Кстати, git log очень полезная команда, её изучению определённо стоит уделить время. Например, полезно знать, что при помощи флага -S мы можем получить список всех коммитов, в которых менялась строка, а соответственно и имя автора коммита.

Или посмотреть все изменения, которые происходили с отдельным файлом:

$ git log --follow -p путь_к_файлу

Последний пример покажет как стереть историю коммитов (фактически удалить . git и запушить с флагом --force):

$ git clone https://github.com/user/user-repo.git
$ cd user-repo
$ rm -rf .git/
$ git init
$ git add .
$ git commit -m 'первый коммит'

$ git remote add origin https://github.com/user/user-repo.git
$ git push --force origin master

А подробнее?

Ну, что ещё? Применительно к github’у можно отметить факт наличия у них Issues. Это такая «примочка», благодаря которой можно ставить задачи для проекта, давать им описание и метку, определяющую к какому разряду данная задача относится (закрытие бага или написание фичи), а ещё назначать ответственного за выполнение определённого issue: всё как у больших.

Итогов подводить не стану. Для заинтересованных лиц ссылочка на неофициальную документацию: The Git Community Book

Почему git ‘pull request’ не называется ‘push request’?



Терминология, используемая для объединения ветви с официальным репозиторием, — это ‘pull request’. Это сбивает с толку, так как кажется, что я прошу перенести мои изменения в официальный репозиторий.

Почему он называется pull-запросом, а не push-запросом?

git github pull-request
Поделиться Источник Alejandro Sanz Díaz     09 февраля 2014 в 09:33

10 ответов


  • Как Github реализовал свою функцию Pull Request

    У меня есть вопрос о GitHub-как они реализовали функцию Pull Request. Сам Git SCM имеет git-request-pull команд. В соответствии с этим ответом GitHub может использовать для этого git-request-pull и git-format-patch . Как они реализовали эту функцию? А насчет Gitorious и Gitlab? Как они сделали то…

  • Git: я не понимаю, как pull-request может работать так, как THIS

    Я хотел бы понять, как делать Git Pull запроса из командной строки. Я нашел документацию об этом здесь: http://git-scm. com/docs/git-request-pull -посмотрите на раздел EXAMPLE). Если я хочу применить эту концепцию, я думаю, что мне придется сделать наш процесс работает следующим образом: # Never…



398

Если у вас есть изменение кода в вашем репозитории и вы хотите переместить его в целевой репозиторий, то:

  • «Push»-это вы заставляете изменения присутствовать в целевом репозитории ( git push ).
  • «Pull» — это целевой репозиторий, который захватывает ваши изменения, чтобы присутствовать там ( git pull из другого РЕПО).

A «pull request»-это когда вы просите целевой репозиторий захватить ваши изменения.

А «push request» бы получилось хранилище с просьбой, чтобы подтолкнуть изменения.

Поделиться Sven     09 февраля 2014 в 11:11



92

Когда вы отправляете запрос на вытягивание, вы просите (запрашиваете) официального владельца РЕПО вытащить некоторые изменения из вашего собственного РЕПО. Следовательно «pull request».

Поделиться JB Nizet     09 февраля 2014 в 09:35



38

tl;dr так как мне не разрешено делать толчок, я просто красиво сделаю запрос владельцу репо, чтобы он решил тянуть


Кто может протолкнуть код в репозиторий?

Должен ли кто-нибудь (возможно, злой, необразованный или неизвестный) прийти и сказать здесь, что я просто толкнул это в вашу главную ветвь и испортил весь ваш код HAHAHA! ?

Ты же не хочешь, чтобы он это сделал. По умолчанию установлена защитная сетка, поэтому никто не может нажать на ваше РЕПО. Вы можете настроить других на сотрудничество , и тогда они смогут подтолкнуть вас. Вы бы предоставили такой доступ людям, которым доверяете.

Поэтому, если вы не являетесь сотрудником и пытаетесь нажать, вы получите некоторую ошибку, указывающую на то, что у вас нет разрешения.


Так как же другие разработчики могут продвигать РЕПО, на которое им не дано разрешения?
Вы не можете предоставить доступ всем, но вы хотите дать другим выход/точку входа, чтобы они могли сделать «запрос владельцу репо, чтобы он вытащил этот код в репо». Проще говоря, сделав РЕПО доступным, они могут fork it…make внести свои изменения в свой собственный fork. Подтолкните их изменения к их собственному fork . Как только он окажется в их собственном удаленном РЕПО:

Они делают запрос на вытягивание из своего fork, и владелец вышестоящего РЕПО (к которому вы не можете подтолкнуть напрямую) решит, следует ли объединять запрос на вытягивание.


Также полу-связанный вопрос, который я рекомендую прочитать, что именно происходит в A git push? Почему isn’t a git push считается так же, как и git merge?

Поделиться Honey     27 сентября 2016 в 15:52


  • Кто может объяснить название «pull request» в git?

    Кто может объяснить название pull request в git? Потому что это метод документооборота для подачи взносов. Мой вопрос касается только имени ‘pull’. Я понимаю часть ‘request’. Что или какое притяжение они имеют в виду? Почему push-запрос, submit request не лучше? Обратите внимание,что я принадлежу…

  • Разница между ‘git request-pull’ и ‘pull request’

    Что такое git request-pull и как это соотносится с созданием pull request , например, на github ? 1. Как это предполагается использовать? 2. Можно ли использовать его в качестве замены для запросов на вытягивание (например, на github)? 3. каковы преимущества его использования?



31

Вытяните запрос: я прошу вас потянуть мой.

Поделиться hepidad     05 ноября 2016 в 03:51



6

Я хочу подтолкнуть что-то к чьему-то РЕПО.

У меня нет разрешения толкать (или тянуть, если уж на то пошло).

Владелец/сотрудники имеют разрешения. Они могут как тянуть, так и толкать. Я не могу давить.

Итак, я прошу их выполнить рывок от меня — что косвенно означает, что я прошу их принять мой толчок.

Так что никаких просьб о толчке. Только для того, чтобы потянуть. И за принятие толчка.

Следовательно, запрос ‘pull’. И не просьба ‘push’.

Поделиться user11705414     26 июня 2019 в 21:10



4

Именно слово «Request» является ключевым в этих действиях. Вы также можете думать об этом как о том, чтобы сказать: «у меня есть просьба к вам взять мою работу, вы принимаете?» — «A Pull Request».

Сначала это немного сбивает с толку, но в конце концов имеет смысл.

Поделиться Kyzer     19 сентября 2016 в 01:28



2

Я боюсь, что большинство этих ответов касаются вопроса, Что означает ‘pull request’? или что будет означать ‘push request’? вместо вопроса OP: почему он называется pull-запросом, а не push-запросом?

Обычно такая замена вопросов приемлема, но в этом случае ясно, что OP знает ответы на эти вопросы замены, поэтому отвечать на них не очень полезно.

Только люди из GitHub, которые придумали этот термин, знают наверняка. Однако представляется очевидным, что этот терминологический выбор отражает примерно следующую точку зрения относительно феномена «изменений, поступающих в хранилище извне»: сопровождающий выполняет действие (тянет) .

Однако запрос-это также действие, и исполнитель этого действия-не сопровождающий, а скорее податель (который сделал еще больше действий, а именно работу). Таким образом, термин ‘pull request’ создает путаницу относительно того, кто является агентом . В конечном счете путаница возникает из-за рекурсивной природы запроса: Запрос-это одновременно действие первичного агента и запрос на будущее действие второго агента.

Ситуация вполне аналогична ныне распространенным лингвистическим конструкциям типа «we built our house» (используемым вместо «мы заплатили кому-то другому, чтобы построить наш дом»), в которых ответственность за первичное действие переносится с очевидного исходного агента на вторичного агента, выполняющего управленческую социальную роль.

Из этого можно сделать вывод, что причиной терминологического выбора является легитимация точки зрения о том, что управленческий труд является первоклассным трудом . Более того, причина путаницы в этом терминологическом выборе может заключаться в том, что работники, не являющиеся менеджерами, естественно, имеют другую точку зрения.

Поделиться jimmymathews     04 мая 2020 в 06:48



1

Чтобы лучше понять это и запомнить навсегда, вам нужно представить себе это.

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

Термин “pull requests” происходит от распределенной природы. Вместо того чтобы просто помещать свои изменения в репозиторий (как это было бы с централизованным репозиторием, например с Subversion), вы публикуете свои изменения отдельно и просите сопровождающего внести ваши изменения. Затем сопровождающий может просмотреть изменения и сделать указанное вытягивание.

Таким образом, вы в основном «request» ребята с письменным доступом к РЕПО, в которое вы хотите внести свой вклад, к «Pull» из вашего РЕПО.

Запросы на вытягивание позволяют вам сообщать другим об изменениях, которые Вы перенесли в ветку в репозитории на GitHub. После открытия запроса на вытягивание вы можете обсудить и просмотреть потенциальные изменения с сотрудниками и добавить последующие коммиты, прежде чем ваши изменения будут объединены в базовую ветвь. Github объяснение

Поделиться SPidey     12 декабря 2019 в 09:08



0

Я думаю, что это глупая терминология, потому что я хочу думать, что я хочу что-то сказать вам, а не думать наоборот, прося кого-то другого вытащить мои добавления. Поэтому он должен быть изменен на PUSH REQ. так как я являюсь активной частью. Стрела летит в другую сторону, начиная с меня, а не с Гуфи на другом конце. IMHO.

Поделиться Michael Pauli     16 октября 2019 в 12:28



0

Подумайте вот о чем. Локальный репозиторий против удаленного репозитория.

  • Когда вы толкаете от местного. ( git push ) — другими словами, удаленный репозиторий извлекает из вас коды(локальные).

Вы о чем-то просите. Итак, спросите себя,

  • Вы хотите, чтобы удаленный репозиторий вытягивал у вас коды? — Вытяните Запрос.

Поделиться Jin Lim     28 ноября 2019 в 17:09


Похожие вопросы:


Почему «git push» отклоняется? («git pull» не помогает)

Моя нынешняя ветвь- my_branch . Пытаясь протолкнуть изменения в удаленное РЕПО, я получаю: $ git push Counting objects: 544, done. Delta compression using up to 4 threads. Compressing objects: 100%…


Почему GitHub называет иностранные заявки «Pull Request»?

Мне любопытно, почему GitHub вызывает представления для слияния, Pull requests. Насколько я понимаю, git pull будет тянуть все изменения из удаленного репозитория в текущую рабочую ветвь. Затем…


git + github auto merge commit + pull request

Я разветвил РЕПО vanilla через интерфейс github на vanilla_copy , после этого я делаю: git clone vanilla_copy , через некоторое время я делаю git pull и получаю один новый коммит feature A , и моя…


Как Github реализовал свою функцию Pull Request

У меня есть вопрос о GitHub-как они реализовали функцию Pull Request. Сам Git SCM имеет git-request-pull команд. В соответствии с этим ответом GitHub может использовать для этого git-request-pull и. ..


Git: я не понимаю, как pull-request может работать так, как THIS

Я хотел бы понять, как делать Git Pull запроса из командной строки. Я нашел документацию об этом здесь: http://git-scm.com/docs/git-request-pull -посмотрите на раздел EXAMPLE). Если я хочу применить…


Кто может объяснить название «pull request» в git?

Кто может объяснить название pull request в git? Потому что это метод документооборота для подачи взносов. Мой вопрос касается только имени ‘pull’. Я понимаю часть ‘request’. Что или какое…


Разница между ‘git request-pull’ и ‘pull request’

Что такое git request-pull и как это соотносится с созданием pull request , например, на github ? 1. Как это предполагается использовать? 2. Можно ли использовать его в качестве замены для запросов…


GIT загрузка файлов pull request изменена

Я пытаюсь просто загрузить измененные файлы в pull REQUEST in GIT для deployment цели. Не могли бы вы помочь мне найти лучший способ? На данный момент разработка-это моя ветвь по умолчанию. git…


Почему мой bitbucket-pipelines.yml недействителен для скрипта pull-request

У меня есть файл bitbucket pipeline yaml для проекта, над которым я работаю. Я прекрасно запустил конвейер, когда он был настроен для запуска на push, но с тех пор, как я переключил его на запуск на…


Каковы отношения между git pull-запросом и git pull и git push?

Каковы отношения между git pull-request и git pull и git push ? Предположим, что я и другие одноранговые узлы совместно используют удаленный репозиторий. У каждого из нас есть свой локальный…

Как сделать «pull request» конкретный коммит

У меня была та же ошибка alwaysCurious , поэтому я немного покопался. 1

Обычный случай

A - B - C [master]
         \
          D - E - F - G [feature] 

Вы работаете над проектом, используете отдельную ветвь ( feature ) для зафиксированных изменений ( D-E-F-G ) и хотите создать запрос на вытягивание. Однако вы хотите, чтобы только некоторые коммиты были включены в запрос на вытягивание (E и F )

Процедура здесь та же, что и в ответе Джозефа

# optional: set upstream as remote if it's not
git remote add upstream https://github.com/<upstream_github_username>/<upstream_github_repo_name>.git
# fetch changes
git fetch --all
# create specific branch for your partial pull request
git checkout -b partial-change upstream/master

Теперь вот как это выглядит:

          [partial-change]
A - B - C [master]
         \
          D - E - F - G [feature]

Cherry-выберите свои конкретные коммиты и нажмите на изменения:

git cherry-pick <hash of commit E>
git cherry-pick <hash of commit F>
git push -u origin partial-change

После устранения любого конфликта именно здесь вы получите:

          E1 - F1 [partial-change]
         / 
A - B - C [master]
         \
          D - E - F - G [feature]

Последовательный случай

Если вместо этого вы просто хотите применить все последовательные коммиты вплоть до последнего (или двух или трех), вы можете просто разветвиться на конкретном коммите. Например, здесь мне просто нужны коммиты до E , а не последующие:

git checkout -b partial-consecutive-changes <hash of commit E>
git push -u origin partial-consecutive-changes

A - B - C [master]
         \
          D - E [partial-consecutive-changes]
               \
                F - G [feature]

Ошибка новичка

Последняя процедура также может помочь вам, если вы просто применили последовательные изменения к мастеру, не используя для них определенную ветвь, и теперь хотите выбрать их позже. Это актуально, если вы разветвили проект на C и продолжили работу на master с другими коммитами. Здесь я добавляю звездочку, чтобы сигнализировать о том, что на fork происходят новые изменения:

A - B - C - D* - E* - F* - G* [master]

То, что вы не должны делать, это:

git checkout -b partial-change upstream/master
git cherry-pick <hash of commit D>
git cherry-pick <hash of commit E>
git push -u origin partial-change

В этом случае вы пытаетесь разветвить мастер на G* , и вишневый выбор предыдущих коммитов даст вам предупреждение:

Предыдущий вишневый выбор теперь пуст, возможно, из-за разрешения конфликта.

так как вы добавляете те же самые старые коммиты в новую ветку.

Вместо этого вам следует сделать следующее:

git checkout -b partial-change <hash of commit E>
git push -u origin partial-change

A - B - C - D* - E* - F* - G* [master]
                  \
              D* - E* [partial-change]               

После этого вы будете готовы сделать запрос на вытягивание только с выбранными коммитами.


Записи:

  1. Здесь я расширяю этот замечательный ответ от Шверна.

  2. Чтобы получить последние хэши фиксации(коммита) n , может быть полезно использовать: git log --pretty=oneline --abbrev-commit | head -n

запросов на вытягивание — документация GitKraken

Запрос на вытягивание (иногда называемый запросами на слияние) — это запрос на проверку. Вы просите кого-нибудь проверить изменения в ветке перед слиянием с другой веткой.


Создание запроса на вытягивание

При подключении к удаленному компьютеру на GitHub, GitLab, Bitbucket или Visual Studio Team Services создайте запросы на вытягивание, перетаскивая одну ветвь в другую и выбирая.

Или попробуйте щелкнуть правой кнопкой мыши целевую ветвь и выбрать.

Или щелкните + в разделе запросов на вытягивание на левой панели и выберите репо и ветвь, чтобы создать запрос на вытягивание.

Шаблоны запросов на вытягивание

GitKraken поддерживает шаблоны запросов на вытягивание из GitHub, GitLab и Azure DevOps (включая устаревшие URL-адреса VSTS).

После того, как ваши шаблоны запроса на вытягивание будут зафиксированы на вашем пульте дистанционного управления, поле шаблона появится при создании запроса на вытягивание в GitKraken:

Если вы впервые работаете с шаблонами запросов на вытягивание, рассмотрите следующие инструкции для шаблонов запросов на вытягивание GitHub, GitLab или Azure DevOps.

Правопреемник, ярлыки и рецензенты

Некоторые интеграции позволят вам также добавить исполнителя запроса на вытягивание и метку (метки) в ваш запрос на вытягивание. Затем GitKraken передаст эти значения в вашу удаленную службу при создании запроса на перенос.

Примечание — при создании запроса на вытягивание GitKraken теперь определяет, конфликтует ли ваша исходная ветвь с целевой веткой в ​​модальном окне запроса на вытягивание.

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

Примечание: Поскольку запросы на вытягивание происходят на удаленном компьютере, сначала нажмите на ветку перед созданием запроса.

Черновик запросов на извлечение

Если вы подключены к интеграции с GitHub, вы можете создать черновик запроса на вытягивание, установив этот флажок при создании запроса на вытягивание в GitKraken.

Как следует из названия, это создаст «черновой» запрос на вытягивание в GitHub. Однако обратите внимание, что не все бесплатные или платные планы GitHub поддерживают черновик.Если вы не видите эту опцию, проверьте свой тарифный план GitHub.

GitKraken Доски карт

Свяжите проблемы GitKraken Boards с запросами на вытягивание, просто выполнив поиск имени карты в разделе GitKraken Boards card при создании запроса на вытягивание.

Будет произведен поиск

карт на всех ваших досках GitKraken. Свяжите столько карточек, сколько хотите, с запросом на вытягивание!

GitKraken передает информацию о карте в вашу удаленную службу при создании запроса на вытягивание.Описание запроса на вытягивание будет включать ссылку на указанные данные карты.

На вашей доске GitKraken информация о запросе на вытягивание автоматически заносится в поле Запрос на извлечение на панели сведений о карточках.

После настройки интеграции запросов на вытягивание GitHub в вашу доску GitKraken вы можете активировать автоматическое изменение для перехода вашей карты в новый столбец в момент изменения вашего PR-статуса. Прощай, переключение контекста!


Работа с активными запросами на вытягивание

GitKraken отображает активные запросы на вытягивание на вашем графике с помощью этого значка.

Если вы используете интеграцию с GitHub, GitLab, Azure DevOps или Bitbucket, вы можете навести указатель мыши на запрос на вытягивание на левой панели, чтобы быстро увидеть, когда запрос на вытягивание был открыт и для каких веток.

Для интеграции с GitLab эта всплывающая подсказка также покажет всех правопреемников или метки, связанные с запросом на вытягивание.

А для GitHub эта всплывающая подсказка покажет исполнителей, метки, рецензентов и статус сборки.

Если изменения в ветке выглядят хорошо после проверки, вы или рецензент можете объединить ветку.

Однако, если есть нерешенные вопросы или комментарии, пользователи могут оставить комментарий к запросу на вытягивание.

Если требуются другие изменения, внесите изменения в свой код, а затем зафиксируйте и отправьте в существующую ветку. Обновление вашей ветки также обновляет запрос на перенос.

Подробнее об использовании запросов на вытягивание в нашем блоге.

О запросах на вытягивание — GitHub Docs

Pull-запросы позволяют вам сообщать другим об изменениях, которые вы отправили в ветку репозитория на GitHub.После открытия запроса на вытягивание вы можете обсудить и просмотреть потенциальные изменения с соавторами и добавить последующие коммиты до того, как ваши изменения будут объединены в базовую ветку.

О запросах на вытягивание

Примечание: При работе с запросами на вытягивание помните следующее:

  • Если вы работаете в модели общего репозитория, мы рекомендуем использовать тематическую ветку для запроса на вытягивание. Хотя вы можете отправлять запросы на вытягивание из любой ветки или фиксации, с помощью тематической ветки вы можете отправлять последующие фиксации, если вам нужно обновить предлагаемые изменения.
  • При отправке коммитов в запрос на вытягивание не нажимайте принудительно. Принудительное нажатие может повредить ваш пул-реквест.

После инициализации запроса на вытягивание вы увидите страницу обзора, которая показывает общий обзор изменений между вашей веткой (ветвью сравнения) и базовой ветвью репозитория. Вы можете добавить сводку предлагаемых изменений, просмотреть изменения, внесенные коммитами, добавить ярлыки, этапы и исполнителей, а также @ упомянуть отдельных участников или команды. Для получения дополнительной информации см. «Создание запроса на вытягивание.«

Создав пул реквест, вы можете отправлять коммиты из тематической ветки, чтобы добавить их в существующий пул реквест. Эти коммиты будут отображаться в вашем запросе на перенос в хронологическом порядке, а изменения будут видны на вкладке «Файлы изменены».

Другие участники могут просматривать предложенные вами изменения, добавлять комментарии к обзору, участвовать в обсуждении запроса на вытягивание и даже добавлять коммиты в запрос на вытягивание.

Вы можете просмотреть информацию о текущем статусе развертывания ветки и прошлых действиях по развертыванию на вкладке «Беседа».Дополнительную информацию см. В разделе «Просмотр действий по развертыванию репозитория».

После того, как вы будете довольны предложенными изменениями, вы можете объединить запрос на перенос. Если вы работаете в модели общего репозитория, вы создаете пул-реквест, и вы или кто-то другой объедините свои изменения из вашей функциональной ветки в базовую ветку, которую вы укажете в пул-реквесте. Дополнительные сведения см. В разделе «Объединение запроса на вытягивание».

Если для репозитория требуются проверки статуса, они должны пройти необходимые проверки, прежде чем вы сможете объединить свою ветку с защищенной.Для получения дополнительной информации см. «О защищенных ветках».

Вы можете связать запрос на перенос с проблемой, чтобы показать, что исправление выполняется, и автоматически закрыть проблему, когда кто-то объединяет запрос на перенос. Для получения дополнительной информации см. «Связывание запроса на вытягивание с проблемой».

Советы:

  • Чтобы переключаться между сворачиванием и разворачиванием всех устаревших комментариев рецензии в запросе на вытягивание, удерживайте опцию Alt Alt и щелкните Показать устаревшие или Скрыть устаревшие .Дополнительные сочетания клавиш см. В разделе «Сочетания клавиш».
  • Вы можете сжать коммиты при объединении запроса на перенос, чтобы получить более оптимизированное представление об изменениях. Дополнительные сведения см. В разделе «О слиянии запросов на вытягивание».

Вы можете посетить свою панель управления, чтобы быстро найти ссылки на недавно обновленные запросы на вытягивание, над которыми вы работаете или на которые подписаны. Для получения дополнительной информации см. «О вашей личной панели инструментов».

Черновик запросов на включение

Черновики запросов на вытягивание доступны в общедоступных репозиториях с GitHub Free для организаций и устаревших тарифных планов для каждого репозитория, а также в публичных и частных репозиториях с GitHub Team, GitHub Enterprise Server 2. 17+ и GitHub Enterprise Cloud. Для получения дополнительной информации см. «Продукты GitHub».

Когда вы создаете пул-реквест, вы можете выбрать создание пул-реквеста, готового для проверки, или черновик пул-реквеста. Черновики пул реквестов нельзя объединить, и владельцы кода не получают автоматический запрос на просмотр черновиков пул реквестов. Для получения дополнительной информации о создании черновика запроса на вытягивание см. Разделы «Создание запроса на извлечение» и «Создание запроса на извлечение из вилки».

Когда вы будете готовы получить отзыв по запросу на вытягивание, вы можете пометить черновик запроса на вытягивание как готовый к рассмотрению.Если пометить пулреквест как готовый к рассмотрению, все владельцы кода будут запрашивать рецензии. Вы можете преобразовать запрос на перенос в черновик в любое время. Дополнительные сведения см. В разделе «Изменение этапа запроса на вытягивание».

Различия между коммитами на страницах сравнения и запроса на вытягивание

На страницах сравнения и запроса на вытягивание используются разные методы для вычисления разницы для измененных файлов:

  • Страницы сравнения показывают разницу между кончиком ссылки головы и текущим общим предком (то есть базой слияния) головы и базовой ссылки.
  • Страницы запроса на извлечение показывают разницу между вершиной ссылки головы и общим предком ссылки головы и базы во время создания запроса на извлечение. Следовательно, база слияния, используемая для сравнения, может быть другой.

Дополнительная литература

Создание запроса на вытягивание — GitHub Docs

Создайте запрос на вытягивание, чтобы предлагать и совместно работать над изменениями в репозитории. Эти изменения предлагаются в ветви , которая гарантирует, что ветка по умолчанию содержит только завершенные и утвержденные работы.

Любой человек с разрешениями на чтение репозитория может создать запрос на перенос, но для создания ветки у вас должны быть разрешения на запись. Если вы хотите создать новую ветку для своего пул-реквеста и у вас нет прав на запись в репозиторий, вы можете сначала разветвить репозиторий. Дополнительные сведения см. В разделах «Создание запроса на вытягивание из вилки» и «О вилках».

Вы можете указать, в какую ветку вы хотите объединить свои изменения при создании запроса на вытягивание.Запросы на извлечение могут быть открыты только между двумя разными ветвями.

Примечание : Чтобы открыть запрос на вытягивание в общедоступном репозитории, у вас должен быть доступ на запись к головной или исходной ветке, или, для репозиториев, принадлежащих организации, вы должны быть членом организации, которая владеет репозиторием, чтобы открыть запрос на вытягивание.

Вы можете связать запрос на перенос с проблемой, чтобы показать, что исправление выполняется, и автоматически закрыть проблему, когда кто-то объединяет запрос на перенос.Для получения дополнительной информации см. «Связывание запроса на вытягивание с проблемой».

Изменение диапазона веток и целевого репозитория

По умолчанию запросы на вытягивание основаны на ветке по умолчанию родительского репозитория. Для получения дополнительной информации см. «О ветках».

Если родительский репозиторий по умолчанию неверен, вы можете изменить как родительский репозиторий, так и ветку с помощью раскрывающихся списков. Вы также можете поменять местами головные и базовые ветви с помощью раскрывающихся списков, чтобы установить различия между контрольными точками.Ссылки здесь должны быть названиями веток в вашем репозитории GitHub.

Размышляя о ветвях, помните, что базовая ветвь — это , где должны быть применены изменения , а головная ветвь содержит , какие вы хотели бы применить.

При изменении базового репозитория вы также меняете уведомления для запроса на вытягивание. Каждый, кто может отправить запрос в базовый репозиторий, получит уведомление по электронной почте и увидит новый запрос на вытягивание на своей панели управления при следующем входе в систему.

Когда вы изменяете какую-либо информацию в диапазоне ветвления, области предварительного просмотра «Применить» и «Файлы изменены» обновятся, чтобы отобразить ваш новый диапазон.

Советы :

  • Используя режим сравнения, вы можете настроить сравнения за любой период времени. Для получения дополнительной информации см. «Сравнение коммитов».
  • Сопровождающие проекта могут добавить шаблон запроса на вытягивание для репозитория. Шаблоны включают запросы информации в теле запроса на вытягивание. Дополнительные сведения см. В разделе «О шаблонах задач и запросов на вытягивание».«

Создание запроса на вытягивание

  1. На GitHub перейдите на главную страницу репозитория.

  2. В меню «Ветвь» выберите ветку, содержащую ваши коммиты.

  3. Над списком файлов щелкните Запрос на извлечение .

  4. Используйте раскрывающееся меню base branch, чтобы выбрать ветку, в которую вы хотите объединить свои изменения, затем используйте раскрывающееся меню compare branch, чтобы выбрать тематическую ветку, в которой вы внесли изменения.

  5. Введите заголовок и описание запроса на вытягивание.

  6. Чтобы создать запрос на извлечение, готовый к рассмотрению, щелкните Создать запрос на извлечение . Чтобы создать черновик запроса на вытягивание, используйте раскрывающийся список и выберите Создать черновик запроса на извлечение , затем щелкните Черновик запроса на извлечение . Дополнительные сведения о черновиках запросов на вытягивание см. В разделе «О запросах на вытягивание».

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

Дополнительная литература

Объединение запроса на вытягивание — GitHub Docs

По завершении работы объединить запрос на вытягивание с восходящей ветвью. Любой, у кого есть push-доступ к репозиторию, может завершить слияние.

О слиянии запросов на вытягивание

В запросе на вытягивание вы предлагаете объединить изменения, внесенные в головную ветвь, в базовую ветвь. По умолчанию любой запрос на перенос может быть объединен в любое время, если только головная ветвь не конфликтует с базовой.Однако могут быть ограничения на то, когда вы можете объединить запрос на перенос в конкретную ветку. Например, вы можете объединить пул-реквест с ветвью по умолчанию только в том случае, если проходят необходимые проверки статуса. Для получения дополнительной информации см. «О защищенных ветках».

Вы можете настроить пул-реквест на автоматическое слияние, когда все требования слияния выполнены. Дополнительные сведения см. В разделе «Автоматическое объединение запроса на перенос».

Если запрос на перенос имеет конфликты слияния или если вы хотите протестировать изменения перед слиянием, вы можете проверить запрос на перенос локально и объединить его с помощью командной строки.

Вы не можете объединить черновик запроса на вытягивание. Дополнительные сведения о черновиках запросов на вытягивание см. В разделе «О запросах на вытягивание».

У вас может быть автоматическое удаление головных ветвей после объединения запросов на вытягивание в вашем репозитории. Для получения дополнительной информации см. «Управление автоматическим удалением ветвей».

Если вы решите, что не хотите, чтобы изменения в ветке темы были объединены с ветвью восходящего потока, вы можете закрыть запрос на перенос без объединения.

Объединение запроса на вытягивание на GitHub

  1. Под именем репозитория щелкните Запросы на извлечение .

  2. В списке «Запросы на извлечение» щелкните запрос на извлечение, который нужно объединить.

  3. В зависимости от параметров слияния, включенных для вашего репозитория, вы можете:

    Примечание: Rebase и merge всегда обновляют информацию о коммиттере и создают новые SHA коммитов. Дополнительные сведения см. В разделе «О слиянии запросов на вытягивание».

  4. При появлении запроса введите сообщение фиксации или примите сообщение по умолчанию.

    Информацию о сообщениях фиксации по умолчанию для слияний сквоша см. В разделе «О слияниях запросов на вытягивание.»

  5. Если у вас есть несколько адресов электронной почты, связанных с вашей учетной записью GitHub, щелкните раскрывающееся меню адреса электронной почты и выберите адрес электронной почты, который будет использоваться в качестве адреса электронной почты автора Git. В этом раскрывающемся меню отображаются только подтвержденные адреса электронной почты. Если вы включили конфиденциальность адреса электронной почты, то @ users.noreply.github.com является адресом электронной почты автора фиксации по умолчанию. Дополнительные сведения см. В разделе «Настройка адреса электронной почты для фиксации».

    Примечание: Селектор электронной почты недоступен для слияний с перебазированием, которые не создают фиксацию слияния, или для слияний сквоша, при которых пользователь, создавший запрос на извлечение, является автором сжатой фиксации.

  6. Щелкните Подтвердите слияние , Подтвердите сжатие и слияние или Подтвердите перебазирование и слияние .

  7. При желании удалите ветку. Благодаря этому список веток в вашем репозитории будет аккуратным.

Репозиторий можно настроить так, чтобы головная ветвь для запроса на вытягивание автоматически удалялась при объединении запроса на вытягивание. Для получения дополнительной информации см. «Управление автоматическим удалением ветвей.«

Примечание: Если вы удалите головную ветвь после того, как ее запрос на вытягивание был объединен, GitHub проверит любые открытые запросы на вытягивание в том же репозитории, которые указывают удаленную ветвь в качестве своей базовой ветви. GitHub автоматически обновляет любые такие запросы на вытягивание, меняя их базовую ветвь на базовую ветвь объединенного запроса на вытягивание. Для получения дополнительной информации см. «О ветках».

Pull-запросы объединяются с использованием параметра --no-ff , за исключением пул-реквестов со сжатыми или перебазированными коммитами, которые объединяются с использованием параметра быстрой перемотки вперед.

Вы можете связать запрос на перенос с проблемой, чтобы показать, что исправление выполняется, и автоматически закрыть проблему, когда кто-то объединяет запрос на перенос. Для получения дополнительной информации см. «Связывание запроса на вытягивание с проблемой».

Дополнительная литература

Комментарий к запросу на извлечение

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

Вы можете прокомментировать вкладку Разговор запроса на вытягивание, чтобы оставить общие комментарии, вопросы или реквизиты. Вы также можете предложить изменения, которые автор запроса на перенос может применить прямо из вашего комментария.

Вы также можете комментировать определенные разделы файла на вкладке «Файлы изменены» запроса на вытягивание в форме комментариев отдельных строк или как часть проверки запроса на вытягивание. Добавление строковых комментариев — отличный способ обсудить вопросы о реализации или оставить отзыв автору.

Для получения дополнительной информации о добавлении комментариев к строке при проверке запроса на вытягивание см. «Просмотр предлагаемых изменений в запросе на вытягивание».

Примечание: Если вы ответите на запрос на вытягивание по электронной почте, ваш комментарий будет добавлен на вкладку Разговор и не будет частью проверки запроса на вытягивание.

Чтобы ответить на существующий строковый комментарий, вам нужно перейти к комментарию на вкладке Разговор или Файлы изменены на вкладке и добавить под ним дополнительный строчный комментарий.

Советы:

  • Комментарии к запросу на извлечение поддерживают то же форматирование, что и обычные комментарии на GitHub, такие как @mentions, emoji и ссылки.
  • Вы можете добавлять реакции на комментарии в запросах на вытягивание на вкладке Файлы изменены .
  1. Под именем репозитория щелкните Запросы на извлечение .

  2. В списке запросов на вытягивание щелкните запрос на вытягивание, в котором вы хотите оставить строковый комментарий.

  3. В запросе на вытягивание щелкните Файлы изменены .

  4. Наведите указатель мыши на строку кода, к которой вы хотите добавить комментарий, и щелкните синий значок комментария. Чтобы добавить комментарий к нескольким строкам, щелкните и перетащите, чтобы выбрать диапазон строк, затем щелкните синий значок комментария.

  5. В поле комментария введите свой комментарий.

  6. При желании, чтобы предложить конкретное изменение линии или строк, щелкните, а затем отредактируйте текст в блоке предложений.

  7. Когда закончите, нажмите Добавить комментарий .

Любой, кто просматривает пулреквест или репозиторий, получит уведомление о вашем комментарии.

Разрешение разговоров

Вы можете разрешить диалог в запросе на вытягивание, если вы открыли запрос на извлечение или если у вас есть доступ на запись в репозиторий, в котором был открыт запрос на извлечение.

Чтобы указать, что диалог на вкладке Файлы изменены завершен, щелкните Разрешить диалог .

Вся беседа будет свернута и помечена как разрешенная, что упростит поиск бесед, которые все еще нужно адресовать.

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

Дополнительная литература

запросов на вытягивание | Учебник Atlassian Git

Pull-запросы — это функция, которая упрощает совместную работу разработчиков с помощью Bitbucket.Они предоставляют удобный веб-интерфейс для обсуждения предлагаемых изменений перед их интеграцией в официальный проект.

В своей простейшей форме запросы на вытягивание — это механизм, с помощью которого разработчик уведомляет членов команды о том, что они выполнили функцию. Как только их функциональная ветка готова, разработчик отправляет запрос на вытягивание через свою учетную запись Bitbucket. Это позволяет всем участникам узнать, что им нужно просмотреть код и объединить его с ветвью master .

Но пул-реквест — это больше, чем просто уведомление — это специальный форум для обсуждения предлагаемой функции.Если есть какие-либо проблемы с изменениями, товарищи по команде могут оставить отзыв в запросе на вытягивание и даже настроить функцию, отправив последующие коммиты. Вся эта активность отслеживается непосредственно внутри запроса на вытягивание.

По сравнению с другими моделями совместной работы это формальное решение для совместного использования коммитов значительно упрощает рабочий процесс. SVN и Git могут автоматически отправлять уведомления по электронной почте с помощью простого скрипта; однако, когда дело доходит до обсуждения изменений, разработчикам обычно приходится полагаться на цепочки писем.Это может стать случайным, особенно когда задействованы последующие коммиты. Запросы на извлечение помещают все эти функции в удобный веб-интерфейс рядом с вашими репозиториями Bitbucket.

Анатомия запроса на вытягивание

Когда вы отправляете запрос на вытягивание, все, что вы делаете, это запрашиваете , чтобы другой разработчик (например, сопровождающий проекта) перетащил ветку из вашего репозитория в свой репозиторий. Это означает, что вам необходимо предоставить 4 части информации для подачи запроса на вытягивание: исходный репозиторий, исходная ветка, конечный репозиторий и конечная ветвь.

Bitbucket устанавливает для многих из этих значений разумные значения по умолчанию. Однако в зависимости от вашего рабочего процесса совместной работы вашей команде может потребоваться указать разные значения. На приведенной выше диаграмме показан пул-реквест, который просит объединить функциональную ветку с официальной главной ветвью, но есть много других способов использования пул-реквестов.

Как это работает

Запросы на извлечение

можно использовать в сочетании с рабочим процессом Feature Branch, рабочим процессом Gitflow или рабочим процессом разветвления.Но для запроса на вытягивание требуются либо две отдельные ветви, либо два отдельных репозитория, поэтому они не будут работать с централизованным рабочим процессом. Использование запросов на вытягивание с каждым из этих рабочих процессов немного отличается, но общий процесс выглядит следующим образом:

  1. Разработчик создает функцию в выделенной ветке своего локального репо.

  2. Разработчик помещает ветку в общедоступный репозиторий Bitbucket.

  3. Разработчик отправляет запрос на вытягивание через Bitbucket.

  4. Остальная часть команды просматривает код, обсуждает его и изменяет.

  5. Сопровождающий проекта объединяет функцию в официальный репозиторий и закрывает запрос на перенос.

Остальная часть этого раздела описывает, как запросы на вытягивание могут использоваться в различных рабочих процессах совместной работы.

Feature Branch Workflow с запросами на извлечение

Рабочий процесс Feature Branch использует общий репозиторий Bitbucket для управления совместной работой, а разработчики создают функции в изолированных ветвях.Но вместо того, чтобы сразу объединять их в master , разработчики должны открыть запрос на вытягивание, чтобы инициировать обсуждение функции, прежде чем она будет интегрирована в основную кодовую базу.

В рабочем процессе Feature Branch есть только один общедоступный репозиторий, поэтому репозиторий назначения запроса на вытягивание и исходный репозиторий всегда будут одинаковыми. Как правило, разработчик указывает свою функциональную ветвь как исходную, а главную как конечную.

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

Также можно подать запрос на включение незавершенной функции. Например, если у разработчика возникли проблемы с реализацией определенного требования, он может отправить запрос на вытягивание, содержащий информацию о незавершенной работе.Затем другие разработчики могут предоставить предложения внутри запроса на перенос или даже сами решить проблему с помощью дополнительных коммитов.

Рабочий процесс Gitflow с запросами на извлечение

Рабочий процесс Gitflow похож на рабочий процесс Feature Branch, но определяет строгую модель ветвления, разработанную для выпуска проекта. Добавление запросов на вытягивание в рабочий процесс Gitflow дает разработчикам удобное место для обсуждения ветки выпуска или ветки обслуживания, пока они работают над ней.

Механика запросов на вытягивание в рабочем процессе Gitflow точно такая же, как и в предыдущем разделе: разработчик просто отправляет запрос на вытягивание, когда необходимо проверить функциональность, выпуск или ветку исправления, а остальная часть команды будет уведомлена через Bitbucket.

Функции

обычно объединяются в ветвь develop , а ветви выпуска и исправления объединяются в обе ветви develop и master . Запросы на извлечение могут использоваться для формального управления всеми этими слияниями.

Разветвление рабочего процесса с запросами на извлечение

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

Аспект уведомления о запросах на вытягивание особенно полезен в этом рабочем процессе, поскольку сопровождающий проекта не имеет возможности узнать, когда другой разработчик добавил коммиты в свой репозиторий Bitbucket.

Поскольку каждый разработчик имеет свой собственный общедоступный репозиторий, исходный репозиторий запроса на вытягивание будет отличаться от целевого репозитория. Исходный репозиторий — это общедоступный репозиторий разработчика, а исходная ветвь — это та, которая содержит предлагаемые изменения. Если разработчик пытается объединить эту функцию с основной кодовой базой, то целевой репозиторий является официальным проектом, а конечная ветвь — master .

Запросы на извлечение

также можно использовать для сотрудничества с другими разработчиками вне официального проекта.Например, если разработчик работал над функцией с товарищем по команде, он мог подать запрос на вытягивание, используя репозиторий Bitbucket товарища по команде для места назначения вместо официального проекта. Затем они будут использовать одну и ту же функциональную ветвь для исходной и целевой ветвей.

Два разработчика могли обсудить и разработать эту функцию внутри запроса на вытягивание. Когда они закончат, один из них отправит еще один запрос на перенос с просьбой объединить эту функцию с официальной главной веткой.Такая гибкость делает запросы на вытягивание очень мощным инструментом совместной работы в рабочем процессе Forking.

Пример

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

В этом примере Мэри — разработчик, а Джон — сопровождающий проекта. У обоих есть свои собственные общедоступные репозитории Bitbucket, а у Джона есть официальный проект.

Мэри является форком официального проекта

Чтобы начать работу над проектом, Мэри сначала нужно разветвить репозиторий Bitbucket Джона. Она может сделать это, войдя в Bitbucket, перейдя в репозиторий Джона и нажав кнопку Fork .

После ввода имени и описания разветвленного репозитория у нее будет серверная копия проекта.

Мэри клонирует свой репозиторий Bitbucket

Затем Мэри необходимо клонировать репозиторий Bitbucket, который она только что разветвила.Это даст ей рабочую копию проекта на ее локальном компьютере. Она может сделать это, выполнив следующую команду:

  git clone https: //[email protected]/user/repo.git  

Имейте в виду, что git clone автоматически создает пульт origin , который указывает на разветвленный репозиторий Мэри.

Мэри разрабатывает новую функцию

Прежде чем она начнет писать какой-либо код, Мэри необходимо создать новую ветвь для функции. Эту ветвь она будет использовать как исходную ветвь запроса на вытягивание.

  git checkout -b some-feature 
# Редактировать код
git commit -a -m "Добавить первый черновик некоторой функции"

Мэри может использовать столько коммитов, сколько ей нужно для создания объекта. А если история функции более запутанная, чем ей хотелось бы, она может использовать интерактивную перебазировку, чтобы удалить или отменить ненужные коммиты. Для более крупных проектов очистка истории функции значительно упрощает для сопровождающего проекта, что происходит в запросе на перенос.

Мэри помещает эту функцию в свой репозиторий Bitbucket

После того, как ее функция завершена, Мэри помещает ветку функции в свой собственный репозиторий Bitbucket (не официальный репозиторий) с помощью простого git push :

  git push origin some-branch  

Это делает ее изменения доступными для сопровождающего проекта (или любых соавторов, которым может потребоваться доступ к ним).

Мэри создает запрос на вытягивание

После того, как Bitbucket получит свою функциональную ветку, Мэри может создать запрос на вытягивание через свою учетную запись Bitbucket, перейдя в свой разветвленный репозиторий и нажав кнопку Pull request в правом верхнем углу. Результирующая форма автоматически устанавливает репозиторий Мэри в качестве исходного репозитория и просит ее указать исходную ветвь, целевой репозиторий и целевую ветвь.

Мэри хочет объединить свою функцию с основной кодовой базой, поэтому исходная ветвь является ее ветвью функции, целевым репозиторием является общедоступный репозиторий Джона, а конечной ветвью является master .Ей также нужно будет предоставить заголовок и описание для запроса на перенос. Если есть другие люди, которым необходимо утвердить код, кроме Джона, она может ввести их в поле Reviewers .

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

Джон просматривает запрос на вытягивание

Джон может получить доступ ко всем запросам на извлечение, которые подали люди, щелкнув вкладку Запрос на извлечение в своем собственном репозитории Bitbucket.Нажав на запрос на перенос, Мэри покажет ему описание запроса на перенос, историю фиксации функции и все изменения, которые он содержит.

Если он думает, что функция готова к слиянию с проектом, все, что ему нужно сделать, это нажать кнопку Merge , чтобы утвердить запрос на вытягивание и объединить функцию Мэри с его основной веткой .

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

Мэри добавляет последующую фиксацию

Если у Мэри есть какие-либо вопросы по поводу отзыва, она может ответить в запросе на вытягивание, рассматривая его как форум для обсуждения своей функции.

Чтобы исправить ошибку, Мэри добавляет еще одну фиксацию в свою ветку функций и помещает ее в свой репозиторий Bitbucket, как и в первый раз.Эта фиксация автоматически добавляется к исходному запросу на вытягивание, и Джон может снова просмотреть изменения прямо рядом со своим исходным комментарием.

Джон принимает запрос на вытягивание

Наконец, Джон принимает изменения, объединяет функциональную ветвь с главной и закрывает запрос на вытягивание. Эта функция теперь интегрирована в проект, и любые другие разработчики, работающие над ней, могут перенести ее в свои локальные репозитории с помощью стандартной команды git pull .

Куда идти дальше

Теперь у вас должны быть все инструменты, необходимые для интеграции запросов на вытягивание в существующий рабочий процесс.Помните, что запросы на вытягивание не заменяют ни один из рабочих процессов совместной работы на основе Git, а скорее удобное дополнение к ним, которое делает совместную работу более доступной для всех членов вашей команды.

Учебное пособие по запросу на извлечение

от yangsu

Что такое запрос на слияние?

из Github с использованием запросов на извлечение страницы

Pull-запросы позволяют сообщать другим об изменениях, внесенных вами в репозиторий GitHub. После отправки запроса на вытягивание заинтересованные стороны могут просмотреть набор изменений, обсудить возможные модификации и даже при необходимости отправить последующие коммиты.

Запросы на извлечение

обычно используются командами и организациями, сотрудничающими с использованием модели общего репозитория, в которой каждый использует единый репозиторий, а тематические ветки используются для разработки функций и изоляции изменений. Многие проекты с открытым исходным кодом на Github используют пул-реквесты для управления изменениями от участников, поскольку они полезны для предоставления способа уведомить сопровождающих проекта об изменениях, которые они сделали, а также для инициирования проверки кода и общего обсуждения набора изменений перед объединением с основным. ответвляться.

Вот пример запроса на вытягивание из репозитория jQuery на github.

Создание запроса на включение

При работе с запросами на вытягивание существует 2 основных рабочих процесса:

  1. Pull Request из разветвленного репозитория
  2. Pull Request из ветки в репозитории

Здесь мы сосредоточимся на 2.

Создание тематической ветви

Во-первых, нам нужно создать ветку из последней фиксации на главном сервере. Убедитесь, что ваш репозиторий обновлен, используя

Примечание: git pull выполняет git fetch , за которым следует git merge для обновления локального репо с удаленным репо.Для более подробного объяснения см. Этот пост stackoverflow.

Чтобы создать ветку, используйте git checkout -b [] , где base-branch-name является необязательным, а по умолчанию — master . Я собираюсь создать новую ветку под названием pull-request-demo из основной ветки и отправить ее в github.

 git checkout -b демо-запрос на вытягивание
git push origin запрос на вытягивание демо
 

Создание запроса на слияние

Чтобы создать запрос на перенос, вы должны зафиксировать изменения в вашей новой ветке.

Перейти на страницу репозитория на github. И нажмите кнопку «Pull Request» в заголовке репо.

Выберите ветку, которую вы хотите объединить, с помощью раскрывающегося списка «Головная ветка». Остальные поля следует оставить как есть, если вы не работаете из удаленной ветки. В этом случае просто убедитесь, что базовое репо и базовая ветка установлены правильно.

Введите заголовок и описание для запроса на вытягивание. Помните, что вы можете использовать Github Flavored Markdown в описании и комментариях

Наконец, нажмите зеленую кнопку «Отправить запрос на перенос», чтобы завершить создание запроса на перенос.

Теперь вы должны увидеть открытый запрос на вытягивание.

Использование запроса на слияние

Вы можете писать комментарии, связанные с запросом на вытягивание,

просмотреть все коммиты, содержащиеся в запросе на перенос на вкладке коммитов,

или просмотрите все изменения файлов из запроса на вытягивание во всех коммитах на вкладке «Файлы изменены».

Вы можете оставить комментарий к определенной строке в изменении кода, просто наведя курсор на строку слева и щелкнув синий значок заметки.

Объединение запроса на слияние

Когда вы и ваши соавторы довольны изменениями, вы начинаете объединять изменения обратно в мастер. Есть несколько способов сделать это.

Во-первых, вы можете использовать кнопку github «Merge pull request» в нижней части вашего pull request, чтобы объединить ваши изменения. Это доступно только тогда, когда github может определить, что не будет конфликтов слияния с базовой веткой. Если все пойдет хорошо, вам просто нужно добавить сообщение о фиксации и нажать «Подтвердить слияние», чтобы объединить изменения.

Локальное слияние

Если пул-реквест не может быть объединен онлайн из-за конфликтов слияния, или вы хотите протестировать что-то локально перед отправкой слияния в репо на Github, вы можете вместо этого выполнить слияние локально.

Вы можете найти инструкции для этого, щелкнув значок (i) на панели слияния.

Однако есть альтернатива, которая может быть лучше для давно существующих ветвей.

Пик для тыквы, перебазирования и вишни

В давно существующих ветвях слияние может часто вызывать множество проблем при обновлении, если изменения в данной ветке конфликтуют с изменениями, недавно слитыми в основную ветвь.Если есть много коммитов в один и тот же файл, git merge может заставить вас исправлять одни и те же конфликты слияния снова и снова, вызывая настоящую головную боль. Хотя есть много способов смягчить эту проблему, например, включение git rerere для повторного использования записанного разрешения конфликтных слияний, объединение серии связанных изменений в 1 коммит и выбор их в мастере — отличное решение, особенно для темы ветви и отдельные особенности.

Такой способ слияния дает несколько преимуществ.Во-первых, вам нужно иметь дело с конфликтами слияния только один раз, поскольку все коммиты сжимаются в 1. Во-вторых, каждая фиксация представляет собой полный набор изменений, необходимых для функции или задачи, что позволяет легко выявлять точечные ошибки и другие проблемы, когда они возникать и удалять набор изменений, когда он больше не нужен.

У раздавливания коммитов есть и недостатки. Во-первых, вы потеряете детали и информацию для каждого изменения, поскольку все сжатые изменения сжимаются вместе. Таким образом, чистый эффект такой же.Во-вторых, это может быть опасно и проблематично при неправильном использовании, например, при сжатии коммитов, которые были отправлены на удаленный сервер и , от которого зависит их работа. Поскольку сжатие изменяет историю git, таким образом вы можете вызвать множество конфликтов. Однако, если вы используете это локально или вы единственный человек, работающий в вашей ветке, и вы точно знаете, что делаете.

Для этого используйте следующую команду

-i означает интерактивный режим, а HEAD ~ 10 означает проверку 10 последних коммитов.

Если вы видите ошибку fatal: Need one revision error, это обычно означает, что осталось не так много коммитов. Попробуйте меньшее число.

Откроется редактор с сообщениями git commit, которые выглядят примерно так:

На данном этапе доступно множество опций. Они подробно описаны на этой странице справки github. Здесь я собираюсь просто объединить все изменения в этом запросе на перенос в одно целое. Сохраните и закройте редактор.

Появится следующий экран с просьбой отредактировать сообщения фиксации.Вы можете отредактировать их или просто продолжить. Сохраните и закройте редактор.

После завершения сквоша вы можете отправить его в удаленное репо. В этом случае эти сжатые коммиты были отправлены на сервер. Однако я единственный пользователь этой ветки и могу безопасно принудительно нажать фиксацию для обновления репозитория git.

 git push origin запрос на вытягивание -f
 

Чтобы объединить коммит, мы будем использовать git cherry-pick .

Готово! Github должен обнаружить изменения и обновить запрос на перенос.Затем вы можете пометить запрос на перенос как объединенный и при желании удалить ветку.

Закрытие запроса на слияние

Вы можете просто нажать кнопку «Закрыть» в запросе на перенос, чтобы закрыть его.