Я пытаюсь настроить разумную стратегию удаленного рабочего процесса Git для общих проектов, основанных на кодовой базе, которая приходит из других мест и имеет несколько разновидностей для разных аппаратных платформ. Это не идеальная отправная точка, но не под моим контролем. Многие файлы различны для разных платформ, но модификации для этих проектов очень локальны и идентичны в обоих деревьях. Однако я изо всех сил пытаюсь найти способ разделить различные части в рабочем процессе git. Основы кода достаточно велики, и каждый общий проект будет использовать различное подмножество файлов, то есть каждый проект может касаться 100 файлов из 5000, но каждый проект будет иметь разные 100 файлов.
То, что я хотел бы настроить, - это «независимый от базы» пульт, которому не важно, к какому коду я обращаюсь, чтобы я мог одинаково применять его к каждой базе, а затем отслеживать изменения относительно его «домашней базы». "без пульта не зная ни одной из баз.
Визуально я думаю, чего я хочу достичь - это
Codebase Hardware 1 --------------------------E
\ / / \
Common Project (remote) ---- A -- B -- C----E---F---
\ /
Codebase Hardware 2 ----------------------D
База 1 и база 2 связаны, но довольно расходятся (и много файлов). Что мне нужно, так это когда я делаю коммит в D, но не загрязняю случайные различия между Base 1 и Base 2, но у них нет общей истории.
Я могу добиться этого вручную с помощью файлов сравнения, применив соответствующие файлы сравнения для общего проекта к обоим деревьям, а затем обработав один из них как основной и выполнив сравнение на базе 2, вручную применю к базе 1 и затем выполню коммит. Я не могу понять, как настроить рабочий процесс git для достижения того же, и я чувствую, что должен быть более легкий путь.
Поэтому я хочу, чтобы общий проект отслеживал различия, но ссылался на две (на самом деле многие) разные базы в зависимости от того, над каким деревом я работаю - своего рода необоснованный рабочий процесс.
Base1 и Base2 раньше были обновлениями и поэтому должны были развиваться только на одном за один раз, но теперь у меня есть возможность одновременно поддерживать все сразу. Тем не менее, я мог видеть в будущем выход на пенсию base1, добавление base3 и т. Д.
Итак, один из подходов, которые я попробовал, состоит в том, чтобы создать историю, в которой кодовая база 2 получена из кодовой базы 1, чтобы они имели общую начальную точку - и хотя это работает, это означает, что я должен продолжать расширять репо с помощью 5000 файлов ish, которые не относятся к общему проекту. Учитывая, что разные версии оборудования обновляются несколько раз в год, этим быстро становится трудно управлять, но на данный момент это единственное рабочее решение. Когда я затем нажимаю изменения на пульте, я получаю все в пульте.
Если я понял подмодули и деревья, они также на самом деле не работают, поскольку я не могу перемещать файлы и сегментировать их в зависимости от проекта, поскольку все проекты используют разные и перекрывающиеся подмножества файлов.
Возможен ли более простой способ? Предложения лучшего способа (кроме как не начинать отсюда!)?
Большое спасибо