Лучшая практика управления вариантами проекта в Git?

Question

Мне нужно разработать два проекта Django, которые делят 90% одного и того же кода, но имеют несколько вариантов в нескольких приложениях, шаблонах и в самой модели.

Я использую Git для распределенного управления источником.

Мои требования таковы:

• общий код для обоих проектов разрабатывается в одном месте (среда разработки project1 в)

• периодически это сливается в среду разработки второго проекта (project2)

• варианты не легко инкапсулируются в приложениях. (Например, есть приложения. Такие, как «профили», которые различаются между Проект1 и Project2, но для которых есть также постоянная общая эволюция)

• как Project1 и Проект2 имеют публичные репозитории, так что я могу сотрудничать с другими

• Аналогично, Project1 и Project2 должны иметь серверы разработки, демонстрации, постановки и производства.

• Однако публичный репозиторий не находится на одном сервере в обоих случаях. Так, например, когда я развиваюсь в Project1, я хочу иметь возможность «нажимать» на мой сервер github, но у меня нет материалов Project2.

• есть файлы, такие как local_settings.py, которые полностью отличаются от Проект1 и Project2, но должны быть разделены между несколькими разработчиками каждого проекта

Так что самый лучший способ управления этой ситуацией?

Казалось бы, идеально было бы что-то вроде «отфильтрованного тяги», где вместо .gitignore, говорящего «игнорировать этот файл целиком», могу сказать «проигнорировать этот файл, когда вытаскиваете из этого репо», я не мог видеть что-то подобное в документации, но может быть что-то подобное?

Answer 1

Я бы сделал третье репо, где я бы разместил код, который разделяет проекты. Тогда Project1 и Project2 будут иметь свое собственное репо, и они могут вырваться из этого «общего» третьего репо.

Я думаю, что ваша идея «отфильтрованного притяжения» затруднит работу с mantein.

Answer 2

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

Answer 3

Я хотел бы попробовать подмодули: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules

Answer 4

Учитывая это сайт Django/Pinax, с вариантами, разбросанных в нескольких различных приложениях, я бы не рекомендовал использовать подмодули.

Варианты должны управляться независимо в ветке project1 и ветке project2, устраняя необходимость «фильтровать» результат gitignore.

Если определить некоторые действительно общие коды, они могут в конечном итоге в третьем репо вы могли бы «поддерево объединенном» в project1 и project2 хранилищ (смысл поддерево стратегии слияния является illustrated in this SO answer)

Answer 5

Вы можете использовать два разные ветви git для развития. Когда вы вносите изменения в один, который является общим для другого, просто git-cherrypick их. Вы можете нажимать и натягивать определенные ветви, чтобы никто не нуждался в том, чтобы вы одновременно работали над обоими из них.