Бывает так, что ты работаешь в какой-то ветке B1, которая отведена от B2, и в обеих ветках накапливается 10-15 коммитов, прежде чем ты решаешь слить себе изменения из родительской ветки. Ты делаешь слияние по всем правилам, но в итоге оказывается, что Git принимает решение, что те или иные изменения не вызывают конфликта, и делает слияние "не в ту сторону", в итоге вставляя старые куски из твоей ветки поверх новых кусков из родительской.
Как вы обычно боретесь с таким явлением? Возможно, есть какой-то вариант merge, когда не только конфликтные, но и все остальные изменения предлагаются для просмотра?
Денис Загаевский, у меня тоже еще ни разу такой проблемы не было, в итоге на самом деле помогло делать мерж, поменяв местами активную ветку и ту, которую указываешь для мержа.
B1 допустим develop B2 фича
Переодически подмерживаем B1 в B2 решаем конфликты если есть.
Настало время сливать создаем из B1 промежуточную ветку B3.
Мержим B2 в B3 со squash. Проверяем все изменения еще раз и создаем commit.
Создаем PR B3 в B1 В итоге, у нас красивый Pull Request с одним коммитом и никаких конфликтов.
Да там тонкостей и нет особо. Вся идея что нужно постоянно сливать изменения из основной ветки в свою, можно просто делать pull B1 в B2 А промежуточная ветка создается для красоты, чтобы не захламлять историю. Что такое squash и для чего он нужен найти легко.
Вот например https://ru.stackoverflow.com/questions/433993/%D0%...
iMaximus, да понятно, что нужно сливать постоянно, но бывает так, что есть ветка истории, пускай она будет H1 (не обращаем внимание на предыдущие обозначения веток). От нее отводятся ветки двух задач, T1 и T2. Над каждой веткой работает какой-то разработчик, в итоге кто-то из них успевает первым закончить свою задачу, и беспроблемно вливает свои изменения из T1 в ветку истории H1. При этом его код и код того, кто работал над T2, где-то пересекаются.
В итоге когда тот, кто наконец закончил свою Т2, встает перед проблемой мержа. Сливать изменения между T1 и T2 в процессе - не вариант. Выливать их постепенно в H1 - тоже не вариант, так как по процессу работы нужно сначала ревью, потом тесты, сборка и ручное тестирование. В общем, в итоге встает иногда задача таких вот мержей.
Станислав, Такое бывает часто, не вижу проблемы. Тот кто первый вливает того и тапки. Второй естественно получает конфликт если есть пересечения. Он просто мержит или пулит основную ветку, решает конфликт и делает то что я написал выше. Если они оба уже сделали PR и один залил, то второй просто решает конфликт и делает еще один коммит.
iMaximus, все верно, но тут вышло так, что почему-то изменения более ранние были накачены как актуальные. Я не понял, что произошло, и в итоге решил в пятницу проблему, поменяв местами во время мержа активную ветку и ту, которую указывал для мержа. Все получилось. Повторять не хочу, да и времени на работе нет. Возможно, что я просто под конец недели что-то неверно понял.
