Является ли лучшим решением переписать всю историю моей ветки, чтобы использовать другую папку?
Это зависит от того, являются ли они на данный момент логически разными файлами. Если они логически представляют собой один файл - если изменения для одного проекта в худшем случае не повредят использованию другого проекта, и особенно если одно и то же изменение обычно приносит пользу обоим проектам - тогда вам лучше будет выполнить их объединение. Но если один файл больше не обслуживает обоих мастеров, вам придется разделить их - либо просто переименовав / переместив один, как вы считаете выше, либо с помощью более сложного рефакторинга, если есть причина (например, может быть, какая-то часть файла все еще распространено).
Так что это то, что вы должны определить. Если вы хотите сохранить их отдельно, то можно переписать историю одного проекта, чтобы переместить файл. Это концептуально просто, так что это плюс. Недостатком является то, что он может сломать исторические версии проекта (поскольку он может найти файл другого проекта там, где он ожидает его файл ... если вы не сделаете более тщательную переписку, которая обновляет каждую историческую версию до know что файл перемещен), и если репозиторий является общим, то все пользователи должны будут согласовать обновление до новой истории.
Теперь, если код для проектов в целом настолько не связан, что имеет смысл просто хранить каждую кодовую базу в отдельной папке, тогда вы можете рассмотреть возможность хранения их в отдельных репозиториях. По какой-то причине «монорепос» приобрели некоторую популярность, но на самом деле это не лучшее использование git. Чтобы работать с условиями инструмента, вы должны позволить каждому репо быть домом одного проекта (и, если есть общий компонент, в идеале переместить его в 3-й репозиторий и использовать подмодули git или инструменты сборки, чтобы включить его в качестве зависимости каждого проект).
Но если вы все еще решаете, что хотите, чтобы два проекта совместно использовали историю в будущем и сосуществовали в разных папках в общих коммитах, есть несколько способов сделать это.
Как вы заметили, вы можете попробовать переписать историю ветки. Я не уверен, что это решит проблему, потому что любой из этих файлов, который существовал до того, как вы создали ветвь, все еще будет наблюдаться как «перемещенный» в первом коммите ветки. (Если только вы не переместите его в общую историю, которая предшествует созданию ветви, в этом случае он будет рассматриваться как «перемещенный назад» в следующем коммите other branch ...)
Так что вместо этого вы можете просто настроить работу слияния. Переместив файлы по будущим путям на кончиках их соответствующих веток, вы инициируете слияние, но удерживаете его от фиксации; получить рабочее дерево в нужное состояние; а затем совершить.
Предполагая, что есть некоторые файлы, которые вы буквально намереваетесь объединить, вы можете начать объединение как обычно, потому что конфликты будут препятствовать фиксации. Затем, как часть «разрешения конфликта», вы разберетесь с путями.
git checkout HEAD -- project-1-path
git checkout project-2-branch -- project-2-path
(где project-1-path и project-2-path - это местоположения файлов, в которые вы переместили соответствующие версии рассматриваемого файла, в последних фиксациях для каждой ветви перед слиянием).