В git, как я могу объединить функции, которые были реализованы в ветке «A» в ветку «B»?

Question

Я новичок в git (и управлении версиями в целом), и я пытаюсь решить, как лучше всего реализовать мой рабочий процесс. Я работаю над (личным) проектом, который включает в себя множество «постоянных» ветвей, т. Е. Полностью разделяет программы, которые раздваиваются из общей базы кода и никогда не будут объединены в ведущую ветвь. (Это потому, что я ученый, работающий над симуляционной моделью, и я пробовал много нового, чтобы посмотреть, есть ли у них интересные результаты. Если они это сделают, я в настоящее время копирую всю папку проекта, чтобы я мог вернемся к нему позже. Я нацелен вместо этого использовать ветви git для этой цели.)

Поскольку эти ветви постоянны, я хочу знать, есть ли простой способ использовать функцию, которую я реализовал в одном и передать его другому, сохраняя при этом различия между двумя ветвями. Например, предположим, что дерево моего репозитория выглядит следующим образом:

   model_a 
      /
initial commit 
       \ 
       model_b 

В моем случае, model_a и model_b используют в широком смысле тот же код моделирования для моделирования две разные вещи. Они могут отличаться значениями некоторых параметров и/или некоторых деталей во внутренних циклах кода моделирования, но общая окружающая его инфраструктура будет одинаковой. Теперь, работая над branch_a, предположим, что я реализовать новый способ визуализации результатов:

   model_a --- model_a_with_visualisation_code 
      /
initial commit 
       \ 
       model_b 

То, что я хочу знать, есть ли команда мерзавец Я могу напечатать, что, за исключением конфликтов слияния, приведет это :

   model_a --- model_a_with_visualisation_code 
      /
initial commit 
       \ 
       model_b --- model_b_with_visualisation_code 

другими словами, я хочу взять только те коммиты, которые были использованы, чтобы превратить model_a в model_a_with_visualisation_code, и применять копии этих фиксаций на конец model_b отрасли. По крайней мере, я думаю, это то, чего я хочу.

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

Я надеюсь, что вопрос ясен. Как я уже сказал, я новичок в git, и многие основные концепции все еще немного туманны для меня. Например, я не совсем уверен, являются ли метки в приведенных выше деревьями тегами или ветвями или просто коммиты. Если я неправильно понял, как что-то должно работать, я был бы признателен за любые разъяснения.

Answer 1

cherry_pick Используется для внесения изменений, внесенных в некоторые существующие коммиты. Указав git cherry_pick [branch] вы должны совершить фиксации на кончике указанной отрасли в текущей ветке вы находитесь.

git checkout model_b 
git cherry-pick model_a 

Documentation

Answer 2

Kevin's answer является правильным, и это хороший способ сделать это, если это время от времени. Но, если вы ожидаете получить много этих изменений, я считаю, что постоянный сбор вишни - это PITA. Я бы предположил, что вы создали еще одну ветку, называемую, например, common. Код, который должен попасть в обе ветви идет здесь, и получает объединены в model_a и model_b:

model_a:   E->F->K 
       / /
common: A->B->C->D---->I 
        \  \ 
model_b:   G->H->L 

Answer 3

Да, это возможно (см другие ответы), но я чувствую, что вы могли бы попытаться решить неправильную проблему.

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

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

В противном случае через некоторое время у вас будет большой набор слегка разных ветвей, в которых все будут содержать разные ошибки, и где вы (вероятно) не знаете больше, что есть.