Git централизованный рабочий процесс

Предположим, что разработчики используют централизованный рабочий процесс git, а github имеет 2 файла a.txt и b.txt.

Теперь dev1 успешно запускает c.txt. Теперь, если dev2 толкает d.txt, это не ускоренная перемотка вперед, и он не может нажать и ПРЯМО ТАК, потому что он должен сначала объединить изменения dev1 локально, а затем нажать.

Теперь еще один сценарий. Предположим, что dev1 создает ветку featureC и содержит файл c.txt вместе с a.txt, b.txt и pushes. Аналогично dev2 создает ветку featureD и содержит файл d.txt вместе с a.txt, b.txt и pushes.

Теперь сделан запрос на объединение FeatureC с мастером, и он успешно выполнен. Снова выдается запрос на объединение FeatureD с мастером, и это НЕ ДОЛЖНО быть успешным, но ЭТО. ЭТОГО НЕ МОЖЕТ БЫТЬ!! КАК ЭТО МОГЛО ПРОИЗОЙТИ? Разве это не соответствует вышеуказанному сценарию?

Источник

2 ответа

Решение

Существует постоянная разница между толчком и толчком. Когда вы хотите отправить коммиты на удаленную ветку, локальному репо нужны все коммиты с удаленного и, конечно, коммиты, которые вы хотите протолкнуть. Это не тот случай, когда dev2 толкает коммит для d.txt, не зная ничего о предыдущем коммите, который ввел c.txt.

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

На самом деле это запрос на удаление, в вашем первом случае, когда git говорит dev2 тянуть (объединять), прежде чем он нажмет.

Вы можете всегда вытягивать (ускоренную перемотку вперед или объединять), когда нет конфликтов, но вы можете только подтолкнуть, когда ваша ветка обновлена ​​с удаленной веткой, к которой вы хотите перенести.

Как понять, что совершается

Разработчику в локальном репозитории довольно легко увидеть, какие изменения на самом деле запрашиваются коммитом. Предполагается, что dev1 разветвляется на featureA для разработки какой-то функции от master этим утром. Вечером он хочет увидеть все изменения, которые он сделал, и когда он зарегистрировался, он сделал

git format-patch master..featureA

Все коммиты, пронумерованные по порядку, записываются в файлы NUMBER-TITLE.patch,

Все эти патчи могут быть объединены с origin/master независимо от состояния origin/master (если уже есть новые изменения origin/masterили нет), когда ни один патч не может быть применен к оригиналу / мастеру, упорядоченному по номеру.

Источник

Ситуация, которую вы описываете

dev1:

a---b - master
     \
      c - featureC

DEV2:

a---b - master
     \
      d - featureD

централизованное репо:

a---b - master

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

После того, как dev1 толкает его master к централизованному:

a---b---c - master

Тогда, если dev2 имеет локально a---b---d - master и пытается подтолкнуть это к master на централизованном репо, git жалуется. Что это должно сделать?

Это:

a---b---d - master #nope

было бы неправильно, так как c отбрасывается

Это:

a---b---c    #nope
     \
      +---d

также было бы неправильно, где следует master указать на? Нет возможности для git знать. Отсюда жалоба, master разошлась.

Теперь к вашему второму сценарию.

Я предполагаю, что запросы на извлечение приводят к вытягиванию в централизованном репо.

"сделан запрос на объединение FeatureC с мастером, и он успешно выполнен":

централизованное репо:

      c - featureC
     / \
a---b---x - master

Затем "делается запрос на объединение FeatureD с мастером":

      c - featureC
     / \
a---b---x---y - master
     \     /
      +---d - featureD

Я не вижу причин, почему это не должно работать! Так как в централизованном репо, featureD сливается в master это актуально, и master не разошлись.

Источник
Другие вопросы по тегам