git + частично общие файлы между ветками / репозиториями.Является ли это возможным?

Question

Одна команда в компании, в которой я работаю, имеет следующую проблему. Они разрабатывают приложение, которое будет иметь разную сборку (например, разный дизайн в зависимости от клиента). таким образом, у них есть некоторый код, совместно используемый сборками, и некоторый специфический для сборки. Например. первая сборка имеет (пример не имеет смысла для файлов, это просто для понимания проблемы; я не знаю точно, какой код отличается)

/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. Все остальное отличается. Проект, конечно, намного сложнее, поэтому не очень удобно хранить все в одном проекте ... Но создавать разные ветки и фиксировать один и тот же код для всех не очень удобно ...

возможно, я выбрал неправильное направление, думая об этой проблеме, но я просто взглянул на git (мы используем svn), и он позволяет разделять репозитории. Вопрос в том, можно ли создавать разные ветки в git, но скажите ему, что «эти файлы должны быть общими для них», а другие файлы должны быть только в этих ветках. Затем, когда разработчик фиксирует class1.java, git синхронизирует его во всех ветках / репозиториях и т. Д. Может быть, есть другое решение, которое может быть легко принято?

Answer 1

можно ли создавать разные ветки в git, но скажите ему, что "эти файлы должны быть общими для них", а другие файлы должны быть только в этих ветках.

Err ... нет.
Когда вы создаете ветку, это фактически означает, что любой будущий коммит любого файла будет записан в этой новой ветке.
Поэтому, если вы не коснетесь class1.java, его фиксация все равно будет ссылаться на исходную ветку (скажем, 'common'), в то время как class2.java будет удалена, а class3.java добавлена, все в ветке ' project1.
Любой, кто создает ветку project2 из common, будет фактически использовать class1.java.

Затем, когда разработчик фиксирует class1.java, git синхронизирует его во всех ветках / репозиториях и т. Д.

Err ... no bis: разработчик должен будет выбрать class1.java и добавить его к ветви 'common', а затем перебросить все остальные ветви поверх common, чтобы увидеть class1.java эволюция.

Реальным решением было бы git submodules (см. здесь для получения дополнительной информации о том, как обновляются подмодули ), но это включает:

• реорганизация кода:

    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 обновляются во всех других ветках / репо, которым требуется новая «общая» эволюция.