Git: Правильный способ объединения изменений в более ранний коммит (перемотка вручную и повтор?)

Question

Я не уверен, что правильный подход к этому сценарию в git, что бы я ни делал, я получаю странные результаты.

У меня есть версия X файла на коммите A. Со временем этот файл был изменен и теперь находится на коммите A '.

Кто-то отправил мне электронное письмо с файлом X ', который является модифицированной версией файла, который содержался в комитете А. Важно: это изменение является внеполосным (по электронной почте и не git) и устаревшим (изменения к более ранней версии файла).

Я точно знаю, что я «хочу» делать в терминологии git, но я не уверен, что это может быть самым чистым способом: перемотать, зафиксировать, воспроизвести. Я предполагаю, что это должно быть так просто, и я знаю, что git делает это внутренне , когда перезагружается, но я не могу заставить его работать самостоятельно.

Что я сделал:

• Оформить заказ и создать новую ветку B на основе коммита A.
• Скопируйте и вставьте измененный файл
• Передать изменения
• Оформить заказ мастер филиала
• Слияние ветки B

Моя проблема в том, что слияние ветви B с master приводит к конфликту для всех строк в файле.

Изменения в файлах (думаю, поэтому) следующие:

Версия A:

line 1
line 2
line 3

Мастер филиала:

line 1, file 1
line 2, file 1
line 3, file 1

отправленный по электронной почте файл:

line 1
line B
line 3

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

Слияние говорит мне, что ВСЕ строки в документе конфликтуют. Я могу понять, если git просто не может объединить изменения из строки 2 в две ревизии, но я не понимаю, почему все 3 строки помечены как конфликтующие.

Может кто-нибудь помочь мне?

Answer 1

Я не уверен, что это «правильное» решение, но, за исключением другого обходного пути, я приму это:

Настроив git для использования внешнего редактора diff / merge, в данном случаеУдивительный и всемогущий BeyondCompare3, я смог обойти это.BC3 имеет более тонкие «блоки» изменений, обнаруживая модификации в одной строке.Хотя мне все еще приходилось объединять изменения вручную, он помечал только измененные по отдельности строки как измененные (хотя он действительно показал, что Git уже обнаружил измененный гораздо больший окружающий блок, он дал мне возможность переопределить его)

Answer 2

Я думаю, что вы ответили на свой вопрос.

Как видите, мастер ветвления включает в себя изменения во всех строках

При слиянии Git не знает, какой набор изменений важнее для вас. Вы должны сделать этот выбор самостоятельно.

Answer 3

Поправьте меня, если я ошибаюсь, но похоже, что вы действительно хотите запустить git rebase B как последний шаг, а не git merge B.

Однако, у вас все еще может быть конфликт слияния для всех трех строк, потому что строки настолько близки друг к другу, что git не хочет предполагать, что конфликт только в строке 2, а не в строках 1-3.