исходная ситуация:
M0 ----- M1 -- M2 -- M3 -- M4 -- M5
|-- A1 --/\ | |
\-- B1 ---|----/ |
--------- A2 ---------/
2 разработчика работают над одним репозиторием, оба начинают с ответвления от M0.Dev A работает над веткой A1, объединяя ее по окончании M1 с главной.Он напрямую создает новую ветку, работая над функцией A2.В это время B работает на B1 и сливается по окончании в M2.Однако во время этого слияния некоторые важные изменения, сделанные в M1, отбрасываются.B создает больше коммитов сверху (M3, M4).Когда А завершает работу над А2 и хочет объединиться с ведущим (M5), изменения, которые уже были внесены в M1 и, следовательно, были частью M2, удаляются / даже не отображаются как конфликтные.(-> Я предполагаю, что это ожидаемое поведение, так как M4 и A2 совместно используют одного и того же родителя M1?)
текущее состояние:
M0 ----- M1 -- M2 -- M3 -- M4
|-- A1 --/\ /
\-- B1 ---|---<
|----\----- A2 ----------\
M1---M2*-- M3* -- M4* -- M5
Чтобы исправить это, я создал новую ветвь из M1и переделал слияние (M2 *).Затем я сделал ребаз, чтобы добавить M3 * и M4 * поверх M2 *.В итоге мне удалось слить А2 в М4 *, получив желаемый М5.К сожалению, M4 был уже выдвинут к происхождениюТак что, если я захочу открыть pull-запрос на M5, это снова представит неправильную версию M2.-> Поэтому, мой следующий шаг - сделать git push --force origin master
(при этом удостоверившись, что dev B уже внес все свои изменения).Весь этот обходной путь рекомендуется или есть лучший способ справиться с описанной ситуацией?