Как открыть несколько запросов на вытягивание на GitHub

143

Когда я открываю запрос на перенос на GitHub .
Все коммиты с момента моего последнего запроса и все новые автоматически добавляются к этому запросу .

Я не могу контролировать, какие коммиты добавляются, а какие нет.
Когда я пытаюсь открыть другой запрос на перенос, я получаю сообщение об ошибке «Ой! Уже есть запрос на перенос».

Есть ли простой способ открыть несколько запросов на вытягивание без необходимости возиться с командной строкой?

git  github  pull-request 
— Torourke
источник

Ответы:

119

Запросы на вытягивание основаны на ветке.
Единственный способ открыть пул-реквест для нескольких коммитов:

  1. Изолируйте их в отдельную ветку .
  2. Откройте оттуда запросы на вытягивание.
— мипади
источник
3
Хорошо, круто, я думал, это только с мастером. Вы имеете в виду, что я могу создать множество веток (например, функции потока git) и делать запросы на вытягивание для каждой из них ... Попробую!
— Ziyan Junaideen
9
Я только что обнаружил, что ветка сохранила историю предыдущих коммитов, поэтому запрос на вытягивание против восходящего потока по-прежнему включает все коммиты.
— eel ghEEz 01
2
Привет @ eel-gheez, ты придумал, что с этим делать? Как создать изолированные PR без отображения изменений из других веток?
— Джонатан Кросс,
3
Это не решает проблему: когда я пытаюсь создать PR, сравниваются обе ветви (по крайней мере, с одной фиксацией каждая). Что я делаю не так?
— MERose
1
@eelghEEz Вы должны создать новую ветку, git cherry-pick все коммиты, которые вы хотите в эту ветку, а затем сделать запрос на перенос из этой ветки. Это очень важная особенность дизайна git, заключающаяся в том, что каждая фиксация зависит от своей предыдущей фиксации, и фиксации в git должны быть не просто патчем, а патчем, знающим, какой патч был применен до этого. Вот почему нужно создать новую ветку с новыми коммитами, различия которых могут быть такими же, но чьи ссылки на предыдущие коммиты разные.
— MD
11

Самый простой способ сделать это - использовать команду hub ( https://github.com/defunkt/hub ).

Из своей тематической ветки (в данном примере «функция»), для которой вы хотите создать запрос на перенос, вы можете просто запустить:

git pull-request

(не забудьте сначала нажать ветку!)

И он откроет новый запрос на перенос на GitHub для «YOUR_USER: feature».

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

$ git pull-request -i 123
[ attached pull request to issue #123 ]
— Тайлер Рик
источник
3

Вы можете создать Pull Request (PR), создав отдельные ветки для своей работы.

Пример:

  1. Вы оформляете заказ от мастера филиала в филиал work-1.

  2. Вы делаете некоторые коммиты в ветке work-1 как work-1-commit-1 и work-1-commit-2.

  3. Теперь вы создаете PR от работы-1 до мастера. Ваш код можно просмотреть, просмотрев файлы, измененные из PR.

  4. Теперь для дальнейшей работы вы перейдете из ветки work-1 в новую ветку work-2.

  5. Вы делаете некоторые коммиты в ветке work-2 как work-2-commit-1 и work-2-commit-2.

  6. Теперь вы создаете PR от работы-2 до работы-1. Ваш код можно просмотреть, просмотрев файлы, измененные из PR.

Здесь изменения файлов будут иметь только новый код, который вы напишете после work-1-commit-2.

— Тушар Миттал
источник
1

На самом деле вы МОЖЕТЕ сделать это, не создавая другую ветку, но для этого нужно немного поиграться.
Вот шаги:

  1. Определите два диапазона фиксации, которые вы хотите извлечь. Вот что я буду использовать для примера:
    (другой / мастер) A -> B -> C -> D -> E (ваш / мастер)
    Допустим, вы хотите вытащить B и C в одном запросе, а D & E в другом.
  2. Сделайте запрос на перенос. Сделайте так, чтобы левая сторона («База») была зафиксирована A. Для правой стороны («голова») введите номер фиксации C.
  3. Напишите описание вашего первого запроса.
  4. Сделайте еще один запрос. В качестве основы введите номер фиксации C, а для головы введите E (ваш / мастер).
  5. Напишите описание.

На мой взгляд, запрос на перенос рассматривает фиксацию C как точку ветвления. Или что-то.

— Езда
источник
Вы должны оставить other / master как левую, даже если вы добавляете номер фиксации из вашего / master. Также этот метод не позволяет добавлять новые коммиты в запрос на слияние, если потребуются дополнительные изменения.
— frisco
Я опубликовал своего рода продолжение этого ответа, в отличие от некоторой информации на Github, см. Stackoverflow.com/questions/23159860
— Марк Беннетт
Я вижу, что это создаст два PR, которые выглядят правильно, поскольку каждый из них содержит в точности желаемые коммиты. Но, чтобы быть ясным, правильно ли он делает, когда они объединяются? То есть, я вижу, что первый PR правильно объединит B & C с другим / master. Но когда 2-й PR сливается, как он узнает, в какую ветвь слиться? (Поскольку он был создан на коммите 'C', а не на другом / master) Имеет ли значение, в каком порядке PR объединяются? (предположительно так)
— Джонатан Хартли
1

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

— BeanyTheSane
источник
1

Я новичок в Git и GitHub, и у меня был тот же вопрос, что и у OP.

Я нашел решение, которое, вероятно, не было доступно во время OP.

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

Проблема: когда вы создаете первый PR, который пытается превратить развитие в master, все выглядит нормально, но затем после того, как вы внесете изменения для второго PR и объедините их (используя ту же ветку), все изменения находятся в одном PR. .

Мини-решение: создать новую ветку

git branch mini_change_2
git checkout mini_change_2

Теперь вы отправляете код на GitHub и создаете PR, но по умолчанию используется Pull from mini_change_2 to master, за исключением того, что master еще не имеет изменений из первого PR, поэтому он включает все изменения из PR1 и PR2.

Лучшее решение: укажите, с какой веткой вы объединяетесь в PR2.

Не просто принимайте значения по умолчанию при создании второго PR, скажем, вы собираетесь потянуть mini_chnage_2 для разработки, это покажет только изменения в mini_change_2

Теперь создайте новую ветку mini_change_3 и PR к mini_change_3.

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

— Markwusinich
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.