Ответвление другой ветви от PR

#git #merge #branch #rebase #pull-request

Вопрос:

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

Есть еще одна ветвь feature 2 , которая называется частью другого запроса на извлечение, где страница, над которой я работаю, была переработана.

Как лучше всего попасть feature 2 в feature 1 филиал? Должен ли я разветвляться feature 2 , feature 2 сливаться с feature 1 ветвью или feature 1 переключаться на feature 2 нее ?

Ответ №1:

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

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

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

Слияние из feature-2 в feature-1 создаст тот же конечный результат текущей версии feature-1 ветви, но история покажет, что ветвь feature-1 была сначала создана из main / master , в нее были сделаны коммиты, а затем feature-2 была объединена в нее до обоих feature-1 и feature-2 была объединена обратно в ветвь по умолчанию.

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

Ответ №2:

Давайте предположим, что ситуация в вашем филиале выглядит примерно так:

       A---B feature2
     /     
o---o---o dev
         
          C---D---E feature1
 

То, что вы хотите, — это перебазировать свою работу feature1 поверх feature2 :

       A---B feature2
     /
o---o---o dev
         
          A'---B'---C'---D'---E' feature1
 

Для этого вы можете запустить:

 git rebase feature2 feature1
 

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

Фон

Вы можете задаться вопросом, зачем перебазироваться? Ну, потому что это создает четкую историю, независимо от того, в какую ветвь она будет объединена первой dev .

Например, давайте рассмотрим сценарий, в котором feature2 слияние происходит до feature1 :

       A---B feature2
     /     
o---o---o---o dev
         
          A'---B'---C'---D'---E' feature1
 

В этом случае, как только вы перебазируетесь feature1 поверх dev , Git обнаружит , что изменения, внесенные коммитами A , B уже dev внесены, поэтому он удалит их из feature1 :

       A---B feature2
     /     
o---o---o---o dev
             
              C'---D'---E' feature1
 

Как насчет того, если feature1 перебазируется раньше feature2 :

       A---B feature2
     /
o---o---o-----------------------o dev
                              /
          A'---B'---C'---D'---E' feature1
 

То же самое относится и здесь. Как только вы перебазируетесь feature2 поверх dev , A и B будете удалены, feature1 потому что их изменения уже присутствуют в dev :

 o---o---o---------------------o dev, feature2
                            /
          A'---B'---C---D---E feature1
 

Конечно, если новые коммиты были добавлены feature2 после того, как вы перебазировали feature1 их поверх, эти коммиты все равно будут сохранены:

                                 F---G---H feature2
                               /
o---o---o---------------------o dev
                            /
          A'---B'---C---D---E feature1