#git #github
#git #github
Вопрос:
Итак, я сделал PR в GitHub, который был объединен с master. Теперь у меня есть другой PR, для объединения которого потребуется некоторое время, и который был отделен от master до того, как был объединен первый PR.
Теперь я хочу поработать над третьим PR, но он должен быть разветвлен на последнем главном, а также включать изменения, которые были сделаны во 2-м PR, о котором я упоминал (для объединения потребуется время).
Я полагаю, мне нужно будет отделиться от главного, а затем перебазировать ветку 2-го PR поверх новой ветки. Не уверен, что это правильный путь или как именно это сделать.
Как мне интегрировать последнюю версию master, а также изменения из несвязанной ветки в новую ветку?
Комментарии:
1. Можете ли вы обновить 2-й PR, чтобы использовать последний мастер?
2. @Schwern Да, я думаю. Как бы я это сделал?
Ответ №1:
Как мне интегрировать последнюю версию master, а также изменения из несвязанной ветки в новую ветку?
Самое простое, что нужно сделать, это создать новое ответвление от главного и объединить во 2-м PR.
$ git checkout -b 3rdPR master
$ git merge 2ndPR
После того, как 2-й PR будет объединен с master, обновите 3-й PR, снова объединив master с 3-м PR.
$ git checkout 3rdPR
$ git merge master
В качестве альтернативы, переустановите 3rdPR поверх master.
$ git checkout 3rdPR
$ git rebase master
Это приведет к более чистой истории без всех промежуточных слияний обновлений.
Более продвинутая вещь, которую нужно сделать, это сначала перебазировать ваш 2-й PR на master. В любом случае, это хорошая идея, это означает, что 2-й PR обновлен во время проверки. Тогда вы можете просто отделить 2-й PR.
У вас есть это.
G - H [2ndPR]
/
A - B ----- F [master]
/
D - E
Затем перебазируйте.
$ git checkout 2ndPR
$ git rebase master
G1 - H1 [2ndPR]
/
A - B ----- F [master]
/
D - E
(Поскольку вы уже нажали 2ndPR, вам нужно будет принудительно запустить обновление. Не используйте --force , используйте git push --force-with-lease . Объяснение здесь.)
Теперь создайте ответвление от 2ndPR.
$ git checkout -b 3rdPR 2ndPR
G1 - H1 [2ndPR][3rdPR]
/
A - B ----- F [master]
/
D - E
И некоторая работа над 3rdPR.
J - K [3rdPR]
/
G1 - H1 [2ndPR]
/
A - B ----- F [master]
/
D - E
Если обновлен 2ndPR…
J - K [3rdPR]
/
G1 - H1 - L - M [2ndPR]
/
A - B ----- F [master]
/
D - E
…вы можете снова переназначить 3rdPR поверх 2ndPR.
$ git rebase 2ndPR
J1 - K1 [3rdPR]
/
G1 - H1 - L - M [2ndPR]
/
A - B ----- F [master]
/
D - E
Когда 2ndPR объединяется…
J1 - K1 [3rdPR]
/
G1 - H1 - L - M
/
A - B ----- F --------------- N [master]
/
D - E
…перебазируйте 3rdPR на master.
$ git rebase master
G1 - H1 - L - M J2 - K2 [3rdPR]
/ /
A - B ----- F --------------- N [master]
/
D - E
Это сложнее, но это приводит к более контролируемому процессу обновления, более точному контролю качества и более чистой истории, независимо от того, как часто вы обновляете ветки. Это требует уверенности в возможности визуализации репозитория Git.
Ответ №2:
Я полагаю, мне нужно будет отделиться от главного, а затем перебазировать ветку 2-го PR поверх новой ветки. Не уверен, что это правильный путь или как именно это сделать.
Перебазирование, вероятно, займет столько же времени, сколько и его объединение, и может значительно усложнить задачу, если сделано неправильно. Если сомневаетесь, не перебазируйте, просто объедините. Это легче отменить позже, если что-то пойдет не так.
В принципе, в вашем случае (ИМХО) нужно перейти к ветке PR2 (той, для слияния которой требуется много времени), создать новую ветку под названием PR3 (ту, над которой вы будете работать сейчас), а затем оформить PR3, а затем … объединить мастер в PR3.
Да. Я чувствую вашу боль. Это так же, как объединение PR2 в master. Но в конечном итоге вам придется объединить PR2 с master в какой-то момент. Лучше сейчас, чем позже. В большинстве случаев, чем дольше вы откладываете это, тем хуже становятся конфликты.
Кроме того, вам нужно, чтобы в PR3 были изменения как от PR2, так и от самого последнего главного… затем вам нужно объединить их. master в PR2 / 3, PR2 / 3 в master, это не имеет значения. Даже если вы rebase , это все равно приведет к тем же конфликтам. Это потому, что вам нужен контент из обеих ветвей, и это изменения контента из одной ветви, которые конфликтуют с изменениями контента из другой ветви. Если вы хотите оба набора изменений, вы должны разрешить конфликты..
Единственный способ «уйти» от разрешения конфликтов — это запустить PR3 с самого последнего основного сервера, затем вручную просмотреть все изменения из PR2 и повторно применить их вручную как новые коммиты на PR3 (следовательно, на master, поскольку в этом упражнении мы запускаем PR3 на master). После выполнения этого (имеется в виду: копирование каждого изменения в каждый файл и вставка его в нужное место, фиксация, внесение следующего изменения и т.д. и т.п.) Вы получите PR3, содержащий как самый последний основной файл, так и изменения из PR2…
…но на самом деле, то, что вы сделали, было rebase похоже на что-то, только вручную. И вы вручную разрешили все конфликты на лету. Итак, в итоге вы как бы вручную объединили PR2-> master, назвав его PR3, а затем НЕ сказали git, что вы все это объединили и решили все проблемы.
Итак. Серьезно. Я бы посоветовал:
- создайте ветку PR3 на PR2
- оформить заказ PR3
- объединить мастер в PR3 //A
- разрешать конфликты //B
- фиксация //C
- работа над PR3
и в качестве бонуса, результатом A B C является готовый кандидат на PR под названием «наконец-то объединенный PR2 в master»
(также обратите внимание, что в приведенном выше списке дел нет ни одного обновления для PR2 или master. Они остаются нетронутыми. Если что-то пойдет не так с A / B / C, просто удалите ветку PR3 и начните заново)