это хороший план? Вы видите какие-либо недостатки или лучший способ?
Под "это хороший план", я полагаю, вы имеете в виду "этот набор команд - хороший способ сделать то, что я намеревался сделать". В этом отношении есть другие способы, но я бы не сказал, что один из них лучше или хуже.
Отсутствует шаг, если вы хотите, чтобы в окончательном репо были ветви внешнего интерфейса; Я расскажу об этом ниже.
В более общем смысле - я приведу предостережение о том, что почти всегда любая проблема, которую кто-то пытается решить путем объединения нескольких проектов в один репо, заменяется более крупными проблемами, связанными с объединенной структурой. Вам нужно будет определить, являются ли они логически отдельными проектами, но, как правило, я видел, что объединение репо чаще всего было движением в неправильном направлении, чем нет.
Но если вы уверены, что это должен быть один репо, то эти команды (на первый взгляд) кажутся такими же хорошими, как и любые другие. Я думаю, очевидный вопрос, почему бы не попробовать их? Единственное, что может быть повреждено, это только что созданные клоны.
как насчет ветвей интерфейса?
Когда вы fetch из frontend, ваше объединенное репо получит «ссылки на удаленное отслеживание» для каждой из frontend веток. Так что для frontend ветви master вы получите remotes/frontend/master.
Однако они будут удалены при remove удаленном управлении. Для master это не обязательно имеет значение (поскольку вы слили frontend/master в master). Для других веток вы должны указать git оставить ссылку на них - и, конечно, будет удобно, если ссылка, которую он хранит, является веткой. Один из способов сделать это будет
git fetch frontend refs/heads/*:refs/heads/frontend/*
Здесь вы создаете frontend пространство имен для ветвей и добавляете все ветви с frontend в это пространство имен. (Пока у вас еще нет ветки с именем frontend или уже существующего пространства имен ветки frontend в бэкэнд-репо, это нормально. Если у вас есть одна из них по какой-то причине, вам придется используйте другое имя для пространства имен.)
Эти вновь созданные ссылки находятся под refs/heads, поэтому они будут рассматриваться как правильные ветви (а не ссылки удаленного отслеживания), и они не будут удалены при удалении источника. С этого момента они ничем не отличаются от ваших внутренних веток.
Вы можете столкнуться с проблемами при слиянии ветви frontend с master в будущем или нет. git попытается разрешить конфликты, возникающие при перемещении всех файлов; но помните, что git не действительно отслеживает перемещения файлов - вместо этого он восстанавливает их эвристически после факта - так что этот механизм не совершенен.
Если вы беспокоитесь о таких проблемах - или если вы делаете какие-то тестовые слияния и обнаруживаете, что возникнут неприемлемые уровни проблемы - тогда можно было бы переписать историю веток frontend/*, чтобы они выглядели как файлы "всегда были" в папке frontend/. Если бы я это сделал, я бы сделал это перед объединением репозиториев; т.е. сразу после клонирования frontend я бы переписал историю клона вместо создания нового коммита для перемещения файлов.
(Вы предлагаете повторить для каждой ветви тип процедуры, которую вы выполняли на master. Я не уверен, что это сработало бы хорошо, хотя вы могли бы это проверить. Проблема в том, что пока обрабатывается master как слияние несвязанных историй, последующие слияния из других ветвей frontend не будут. Чтобы эти слияния работали правильно, git все равно должен был бы правильно интерпретировать перемещения файла - и фактически должен был бы интерпретировать их правильно с обеих сторон слияния.)
Если вы решите переписать историю frontend, самый простой подход - использовать git filter-branch со сценарием --tree-filter, который перемещает файлы в подкаталог. См. git filter-branch документы для деталей. (https://git -scm.com / Docs / ГИТ-фильтр-филиал )