мерзавец + частично совместно используемые файлы между ответвлениями/репозиториями. Действительно ли это возможно?
У одной команды в компании, на которую я работаю, есть следующая проблема. Они разрабатывают приложение, которое будет иметь различные сборки (например, другой дизайн в зависимости от клиента). таким образом, у них есть некоторый код, совместно использованный сборками и некоторыми характерными для сборки. Например, первая сборка имеет (пример бессмыслен о файлах, это должно только понять проблему; я не знаю точно, какой код отличается),
/src/class1.java
/src/class2.java
/res/image1.png
/res/image2.png
второй проект содержит
/src/class1.java
/src/class3.java
/res/image1.png
/res/image3.png
как Вы видите, у обоих есть class1.java и image1.png. Evething еще отличается. Проект намного более сложен, конечно, таким образом, для содержания всего в одном проекте не удобно... Но также и сделать различные ответвления и передать тот же код всем им не удобны...
вероятно, я выбрал неправильное направление, думающее об этой проблеме, но я просто смотрел на мерзавца (мы используем svn), и это позволяет разделенные репозитории. Вопрос: действительно ли возможно сделать различные ответвления в мерзавце, но сказать этому, что "эти файлы должны быть совместно использованы между ними", и другие файлы должны быть только в тех ответвлениях. Затем то, когда разработчик фиксирует class1.java мерзавца, синхронизирует его во всем branches/repositorias и т.д. Возможно, существует другое решение, которое может быть легко взятый?
1 ответ
можно ли создавать разные ветки в git, но сообщать ему, что «эти файлы должны быть общими для них», а другие файлы должны находиться только в этих ветвях.
Эээ ... нет.
Когда вы создаете ветвь, это фактически означает, что любая будущая фиксация любого файла будет записана в этой новой ветке.
Итак, если вы не коснетесь class1.java , его фиксация все равно будет ссылаться на исходную ветвь (скажем, ' common '), а class2.java будет удален, а class3.java добавлен, все в ветке « project1 ».
Любой, кто создает ветку project2 из common , фактически повторно использует class1.java .
Затем, когда разработчик фиксирует class1.java, git синхронизирует его во всех ветвях / репозиториях и т. Д.
Эээ ... нет бис: разработчику придется выбрать вишневый class1.java и объединить его ветку ' common ', а затем переустановите все остальные ветки поверх common , чтобы увидеть эволюцию class1.java .
Реальным решением были бы подмодули git (см. здесь для получения дополнительной информации о способе обновления подмодулей ), но это включает:
- реорганизацию кода:
project
src
class3.java
# here is a full git repo
common # = referenced within the 'project' repo
# as submodule
src
class1.java
- по-прежнему подталкивает к «общему» репозиторию Git всякий раз, когда изменяется
class1.java, а подмодули git обновляются во всех других ветвях / репозиториях, которые нуждаются в новой «общей» эволюции.