Блог

Главная - Вопросы по программированию - Правильный способ слияния git при изменении базового кода

Правильный способ слияния git при изменении базового кода

#git

#git

Вопрос:

У нас есть некоторый устаревший код, который я пытаюсь привести в более современную парадигму. По сути, они взяли код из вышестоящей команды, удалили из него всю информацию о git, скопировали файлы в пустое хранилище и зафиксировали его. Затем затем добавили свой собственный код поверх него.

Теперь мне нужно переместить этот код на новый базовый уровень. (У меня есть другая цель — создать реальные ветви для этого кода в клонах вышестоящего репозитория, но это другое обсуждение.)

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

Вот основная идея того, что я пробовал:

 A -- B -- [ Baseline code "C" ] -- D -- E -- F ... HEAD
                               
                                
                                 -- [ New baseline "Z" ]  <-- Did a git merge on this branch to bring in the changes on master

В журнале git я вижу коммиты A — F, затем мою базовую «Z», затем коммит слияния от master.

Комментарии:

1. Вы сказали, что они изначально скопировали исходный код в пустое хранилище; но вы определили C ad «базовый код»… итак, что такое A и B ?

2. Куча плохих идей… Они добавили базовый уровень, удалили каталог .repo, вернули базовый уровень. снова добавил базовый код, внес изменения, а затем переместил все в каталог (где файлы должны были быть в первую очередь).

3. Что ж, похоже, что ответом на этот вопрос должно быть no, но это по-прежнему наиболее разумная возможность с точки зрения git: могли ли изменения, которые «отсутствуют», произойти между A и C ? Если это так, то git будет ли это Z предназначено для отмены этих изменений. Вы могли бы подтвердить или исключить эту возможность с помощью git diff A C . В любом случае, вероятно, «безопаснее» использовать Z как дочерний элемент A , а не C .

4. Помимо вышеописанного, процедура, которую вы описали, звучит правильно, по крайней мере, на указанном уровне детализации.

5. Спасибо! Изменения определенно произошли после C. Я проверил это, просмотрев журналы. Я вижу кучу отсутствующих включений и некоторый код в одном из файлов .c, когда я пошел разрешать конфликт «оба изменены». Я беспокоюсь, что если я помещу Z в качестве дочернего элемента A, тогда будут применены коммиты возврата / перемещения между A-C. Поскольку они из двух разных версий (одна намного позже другой), я не уверен точно, что произойдет.