Ответ 1
master----\----commit A----cherry-picked changesets from topic---commit B--\----commit C----merge---
\ \ /
topic-----------------------------------------------------------merge---------/
~~~~~
^
+ here you merged B in topic
Существует слияние уже в теме, которая имеет фиксацию B как родителя. Таким образом, B полностью сливается в тему и больше не будет объединен.
Поскольку у вас нет изменений в теме, вы, по-видимому, вернули их по теме, либо в самом слиянии, либо в следующем коммите. Такое обращение является регулярной фиксацией для алгоритма слияния и не сливается с мастером. Поэтому, когда вы объединяете тему в master, эти изменения фиксации будут объединены, возвращая commit B.
Чтобы получить изменения с B назад, вы должны либо:
- Найдите и верните отмену изменений B в теме.
- Cherry-pick B (
git cherry-pick B) по теме. - Повторите слияние, замените тему после слияния нового слияния и забудьте исходную ветвь, но поскольку это связано с перемоткой, вы можете сделать это только в том случае, если вы управляете всеми репозиториями, имеющими ветвь.
Как изменения могут быть отменены без вашего осознания? Если вы объединяетесь и получаете конфликты, вы можете разрешить их небрежно, используя "местное" мышление, что вам пока не нужны эти изменения. Но из Git (или любой другой системы контроля версий, если это так, 3-стороннее слияние работает одинаково во всех) точка зрения, что вы видели изменения и отклонили их, поэтому вы не получите их снова, когда вы вручную их повторно применяете.
Конфликт, возможно, был легко вызван более ранними вишнями. Хотя алгоритм не будет объявлять конфликт, если обе стороны выглядят одинаково, и поэтому, если вы выбрали вишню и слейте, он будет объявлять конфликт, если вы измените выбранный вишневый код с одной стороны. Скажите, что у вас есть:
----\-- A -------- B' -- B2 --\
\ \
D -- B -- E -----------merge
где B' выбирает B и B2 изменяет тот же код, что и B. В этом случае слияние будет видно, что одна сторона сделала B, а другая сторона сделала B2, потому что вишня-выбор скрыт B2 и таким образом объявит конфликт между B и B2. И если вы не будете внимательно смотреть на историю, вы можете легко решить эту ошибку. Вы можете избежать проблемы, если при выборе фиксации вы тщательно слейте целевую ветку в источник, подобный этому:
----\-- A --------\- B' -\- B2 --\
\ \ \ \
D -- B -- E --m1-----m2----merge
где m1 является нормальным слиянием без участия вишневого захвата, а m2 разрешается с локальной версией, потому что на удаленных видах только вишневые изменения. Это обеспечит бесперебойную работу последующих слияний.
На самом деле для этого можно написать стратегию слияния для Git.