«раздваивать» собственный проект в git

Question

В настоящее время у меня следующая ситуация: мне нужно поддерживать репозиторий, который содержит несколько версий одного и того же проекта в качестве подкаталогов.Давайте назовем dev / самый важный проект "main", а другие проекты "sub_1", ..., "sub_n".

Версии различны, но в основном одинаковы: представьте примеры как проект Androidдля Android 2.1 вместо версии 2.2+, для которой вы разрабатываете, модифицированная таблица стилей CSS для IE6, пользовательская сборка для большого клиента и тому подобное.Каждая версия обычно имеет подмножество «основных» файлов с небольшими изменениями.

В настоящее время я использую следующий метод для изменения файлов в проекте:

• Для 0≤i≤n
• Посмотрите на файлы, которые использует sub_i
• Замените файлы, которые использует sub_i, на правильные из основного
• Различайте изменения, игнорируйте изменения, которые являются частью основного, ноповторно примените sub_i «патчи» к файлам

Очевидно, этот процесс утомителен и подвержен ошибкам.Я искал несколько способов сделать это и, по существу, имею следующее:

• Что я делаю сейчас.Менее чем идеально по описанным причинам
• Ветвление.Это выглядит наиболее многообещающе, но я не знаю, как бы я разветвлял только часть хранилища.(если я делаю полную ветку, у меня все еще нет способа эффективно объединить файлы)
• Подмодули.Они могут работать, но, насколько я понимаю, они будут использоваться только для полностью внешних проектов, а не для копий одного и того же хранилища

Кто-нибудь знает правильный способ сделать это?

Обратите внимание, что желательно поддерживать структуру каталогов / main и / sub_i (git-репозиторий в качестве корневого), поскольку изменение может привести к поломке многих вещей (не самого программного обеспечения, а главным образом средств сборки и т. Д.)

Answer 1

Субрепо подход

Когда я вас правильно понимаю, ваш репо выглядит так:

root
+ main
+ sub_1
+ sub_2
+ sub_N

Где main действует как своего рода библиотека или инфраструктура, а sub_1..sub_N - это более или менее разные ветви одного и того же программного обеспечения. Одним из решений было бы разместить main как подмодуль sub_1..sub_N, поэтому в конце дерево будет выглядеть как

root
+ main (=submodule)
+ source of sub_X, = on branch sub_X

Здесь все ваши sub_1..sub_N папки являются разными ветвями одного репо, а ваша главная / папка - другим репо. Это возможный способ, если все папки sub_X являются производными от общей базы, и на этой общей основе легко разрабатывать и выполнять слияние из общей базы в ветви sub_X для распространения этих изменений. Но у этого сценария есть большой недостаток: ему нужно, чтобы каждый, кто разрабатывает с этой структурой, точно знал, что он делает, так как разработка в ветви sub_X нелегко распространить на общую базу или другие ветви sub_Y посредством слияния, так как слияние операция будет не только передавать новые изменения в другие ветви, но также и изменения, которые отличают ветку sub_X от base или sub_Y. Так что, в общем, я бы советовал против такого подхода.

Специализация

Другой подход состоит в том, чтобы изолировать изменения sub_X и создать базовую версию, которая состоит из всех элементов, которые одинаковы в sub_1..sub_N, так что папки sub_X only состоят из специализированных элементов. Это зависит от вашей стратегии разработки / развертывания.

Реальные ветви

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

1. создание ветки для основной папки (git checkout -b main)
2. удалить все элементы sub_X
3. переместить все основные / * вещи в /

4. совершить

5. для каждой папки sub_X

6. создать ветку sub_x на основе main (git checkout -b sub_x main)
7. удалить все, кроме папки sub_X
8. переместить все элементы sub_x в /
9. совершить

После этого у вас есть график версий, подобный этому:

 -o-o-(past history) - main -- sub_1
     /                      \--sub_2
 -o--                       \--sub_N

Затем вы можете разрабатывать новые функции в основной ветви и объединять эти функции с ветками sub_X. Главное в настройке с несколькими ветвями состоит в том, что вам всегда необходимо выбрать правильную начальную точку для новой разработки, поскольку операция объединения будет передавать нежелательные изменения между ветвями, если вы не использовали правильный запуск точка. Правильная отправная точка - это ревизия, которая является прародительницей всех ветвей, куда должно идти новое изменение. Если вы хотите разработать исправление для чего-то, что затрагивает все ветви sub_X, вам нужно разработать это исправление в main, так как main является общим предком всех ветвей sub_X. OTOH, если у вас есть что-то особенное для sub_23, правильно разработать материал для ветки sub_23.