В конфликте с слиянием вишни или пересоединения Git, как определяются BASE (aka «ancestor»), LOCAL и REMOTE?

Question

В нормальном Git слияния конфликта, три версии файла в игре для трехходового слияния примерно следующим образом:

• LOCAL: версия от моей ветви
• REMOTE: версия от другая ветвь
• БАЗА: версия от общего предка двух ветвей (в частности, общий предок РУКОВОДИТЕЛЯ моего филиала и руководитель другого филиала)

Когда Git вишневого выбор порождает слияния конфликт , нет общего Итак, как же эти вещи определяются? То же самое можно было бы спросить о rebase.

Answer 1

вишневого выбрать

Если я не ввел в заблуждение себя, а затем, если вы делаете «мерзавец вишневого выбрать < совершить C >», то вы получите:

• Локальная: Вы допускаете» повторное объединение сверху (т.е. главы вашей отрасли)
• REMOTE: коммит вы вишневый сбор (т.е. < фиксация C >)
• база: т (родитель C), то есть родитель C)

Если не сразу понятно, почему BASE должно быть C ^, см. раздел «почему» ниже.

Между тем, давайте рассмотрим пример, и видим, что БАЗА может быть но часто не будет общего предка во время вишневого медиатором. Предположим, что коммит график выглядит следующим образом

E <-- master 
| 
D 
| C <-- foo_feature(*) 
|/ 
B 
| 
A 

и вы находитесь в ветке foo_feature (отсюда и звездочка). Если вы делаете «git cherry-pick < commit D >», то BASE для этой вишневой подборки будет фиксацией B, которая является обычным предком C и D. (C будет LOCAL, а D будет REMOTE.) Однако, если вы вместо того, чтобы сделать «мерзавец вишневым выбрать < совершить E >, то база будет совершать D. (C будет LOCAL и Е будет REMOTE.)

перебазироваться

Справочного контексте перебазирования является примерно повторная вишня-сбор.В частности, перебазирования темы на вершине мастера (т.е. «мерзавец контроль тема, мерзавец мастер перебазироваться») означает примерно:

git checkout master # switch to master's HEAD commit 
git checkout -b topic_rebased # create new branch rooted there 
for each commit C in master..topiC# for each topic commit not already in master... 
    git cherry-pick C# bring it over to the new branch 
finally, forget what "topic" used to mean and now defined "topic" as the HEAD of topic_rebased. 

Этикетка, которые применяются во время этого процесса являются расширениями нормальных правил вишневого выбрать:

• LOCAL: коммит вы вишневый сбор на вершине
  • это руководитель нового topic_rebased филиала
  • Для первой фиксации только, что это будет таким же, как рУКОВОДИТЕЛЬ мастера
• УДАЛЕННЫЙ: фиксация, которую вы выбрали из вишни (т. < фиксации C >)
• БАЗЫ: родитель коммита вы будете вишневого комплектование (C ^, т.е. родителю C)

Это подразумевает то, чтобы иметь в виду о LOCAL против REMOTE, если вы хотите, чтобы избежать путаницы:

Даже если вы были на ветке тему, когда вы инициировали Rebase, МЕСТНОГО никогда не относится к фиксации на тему ветвив то время как происходит переформатирование. Вместо этого LOCAL всегда ссылается на фиксацию на ветке, которая создается (topic_rebased).

(Если один не может держать это в виду, то во время сильного слияния один может начать спрашивать себя: «Подождите, почему это говорят эти местные изменения? Я клянусь, они были изменения, сделанные мастером, . не на моей ветке ")

Чтобы быть более конкретным, вот пример:

Скажем, у нас есть обязательство граф

D <-- foo_feature(*) 
| 
| C <-- master 
B | 
|/ 
| 
A 

и мы в настоящее время на branch foo_feature (обозначается символом «*»). Если мы запустим «git rebase master», rebase будет действовать в два этапа:

Во-первых, изменения от B будут воспроизведены поверх C. Во время этого C LOCAL, B - REMOTE, а A - BASE. Обратите внимание, что А является реальным общим предком B и C. После этого первого шага, у вас есть график примерно так:

B' <-- foo_feature 
D | 
| | 
| C <-- master 
B/
|/ 
| 
A 

(В реальной жизни, B и D, возможно, уже подрезали из дерева на данный момент, но я оставляю их здесь, чтобы было легче обнаружить потенциальных потенциальных предков.)

Во-вторых, изменения от D будут воспроизведены поверх B '. Во время этого B 'является ЛОКАЛЬНЫМ, D - ДИСТАНЦИОННЫМ, а B - BASE. Заметим, что B не является соответствующим общим предком чего-либо. (Например, это не общий предок текущего LOCAL и REMOTE, B 'и D. И это не общий предки исходных ветвей ветвей, C и D).После этого шага, у Вас есть ветвь примерно так:

D' <-- foo_feature 
    | 
    B' 
D | 
| | 
| C <-- master 
B/
|/ 
| 
A 

Для полноты записка к концу Rebase B и D удалены из графика, получая:

D' <-- foo_feature 
| 
B' 
| 
C <-- master 
| 
A 

Почему BASE определена так, как есть?

Как отмечено выше, как для вишневого выбора, так и для перестановки, BASE является родительским (C ^) фиксации C. В общем случае C^не является общим предком, так зачем называть его BASE? (В обычном слияния БАЗЫ является общего предка. И часть успехов GIT в слиянии из-за его способности, чтобы найти хороший общий предок.)

По существу, один делает это как способ реализации «заплату» с помощью обычного алгоритма three-way merge. В частности, вы получите эти «пятнистые» свойства:

• Если < фиксации C > не изменяет заданную заданную область файла, то версия этого региона от вашей отрасли будет преобладать. (Это означает, что регионы, которые «патч» не требует изменения, не получают пропатчен.)
• Если < совершает C >, он изменяет данную область файла, и ваша ветка оставляет эту область в покое, а затем версию этот регион от < совершит х > будет преобладать. (То есть, регионы, которые «патч» требует изменения, получили исправление.)
• Если < совершает C >, он изменяет данную область файла, но ваша ветвь также изменила эту область, а затем вы получите конфликт слияния.