Новый пул-запрос, когда он уже открыт - PullRequest
Новая
       11

Новый пул-запрос, когда он уже открыт

0 голосов
/ 03 июля 2019

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

Если я сейчас создам новый запрос на включение, он объединится с предыдущим и создаст один огромный запрос?Или будет два отдельных пиара?Я волнуюсь, что это сольется, потому что в поле коммитов на GH я вижу коммиты от предыдущего PR.

Ответы [ 3 ]

1 голос
/ 03 июля 2019

выяснить следующее 

                  ___ you created a new branch, call it "branch-01" 
                 /       
master branch __/_______________________

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

Сценарий 1: Вы создали PR-ветку-01, которая содержит несколько коммитов, содержащих всю работу, которую необходимо объединить с мастером. Но нуждается в пересмотре, так что это как в ожидании.

Сценарий 2: Вы создали PR-ветку-01, которая содержит несколько коммитов, содержащих некоторые работы. Теперь вам нужны эти изменения, чтобы продолжить следующую работу. Итак, что вы делаете сейчас, если вы находитесь на branch-01, вы делаете git co -b branch-01-next-steps, теперь branch-01-next-steps будет иметь предыдущую работу из branch-01, потому что вы создали новую ветку оттуда. Так что эта ветка находится сверху ветки-01, выглядит так 

                                    ______branch-01-next-steps______
                                   /
                  ____branch-01___/ 
                 /       
master branch __/_______________________

Может быть, это то, что вы хотите и нужно. Но, может быть, вам нужна новая свежая ветка от мастера. Тогда вам нужно сначала git co master, теперь вы находитесь в локальной ветке master. Оттуда вы можете сделать git co -b next-steps, который будет выглядеть как 

                  __branch-01..(waiting)              ___next-steps
                 /                                   / 
master branch __/___________________________________/________

если вам нужно получить изменения от мастера, которые были объединены на удаленном компьютере, прежде чем вы начнете работать над следующими шагами, вы должны сначала перейти к мастеру git co master, затем набрать git pull origin master и затем git co -b next-steps, теперь следующие шаги будут содержит новейшие изменения от удаленного мастера.

Вы всегда можете вернуться к ответвлению 01 с помощью git co branch-01

1 голос
/ 03 июля 2019

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

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

У меня был подобный опыт в прошлом, и я бы отменил / отклонил 1-й пул-запрос (это может понадобиться вашему владельцу репо) вместо того, чтобы объединить его, а вместо этого просто слить изменения из вашего последнего пул-запроса который содержит изменения от обоих. На мой взгляд, это самое простое.

1 голос
/ 03 июля 2019

Вы можете разрабатывать функции друг над другом, нет проблем.Единственное, что для выполнения операций требуется немного больше работы.Итак ... как только ваша первая функция будет объединена с главной (и если вам не нужно было перемещать ее из той точки, где она находится сейчас), вы можете очень легко перебазировать функцию Feature2: 

git checkout feature2
git rebase master

Этоработает, потому что ревизии, из которых была запущена feature2, уже объединены с master.

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

git branch temp feature1 # save current position of feature1, will need it later
git checkout feature1
git rebase feature1
# now... in order to rebase feature2, you have to make sure _not_ to rebase the revisions you have already rebased of feature1
git rebase --onto feature1 temp feature2 # rebase feature2 onto feature1, do _not_ rebase the revisions of the old feature1
git branch -D temp # delete temp branch

Надеюсь, что поможет

...