#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