git + partly shared files between branches/repositories. Is it possible?

Question

One team in company I work for has the following problem. They develop an application, which will have different builds (e.g. different design depending on customer). so they have some code shared between builds, and some specific to build. E.g. first build has (example is meaningless about files, it is just to understand the problem; I don't know exactly which code differs)

/src/class1.java  
/src/class2.java  
/res/image1.png  
/res/image2.png  

second project contains

/src/class1.java  
/src/class3.java  
/res/image1.png  
/res/image3.png  

as you see, both have class1.java and image1.png. Evething else is different. The project is much more complex of course, so to contain everything in one project is not comfortable... But also to make different branches and commit the same code to all of them is not comfortable...

probably I picked wrong direction thinking about this problem, but I just took a look at git (we use svn), and it allows separated repositories. The question is: is it possible to make different branches in git, but tell it that "these files should be shared between them" and other files should be only in those branches. Then when developer commits class1.java git synchronizes it in all branches/repositorias etc. Maybe there is another solution which can be easy taken?

Answer 1

is it possible to make different branches in git, but tell it that "these files should be shared between them" and other files should be only in those branches.

Err... no.
When you create a branch, that actually means that any future commit of any file will be recorded within that new branch.
So if you do not touch to class1.java, its commit will still be reference by the original branch (say 'common'), while class2.java will have been removed, and class3.java added, all in the branch 'project1'.
Anybody creating a branch project2 from common would in effect reuse class1.java.

Then when developer commits class1.java git synchronizes it in all branches/repositorias etc

Err... no bis: the developer would have to cherry-pick class1.java and merge it to the branch 'common', and then rebase all the other branches on top of common in order to see class1.java evolution.

The real solution would be git submodules (see here for more on the way submodules are updated), but that involves:

• a reorganization of the code:

    project
      src
        class3.java
                       #   here is a full git repo
      common           # = referenced within the 'project' repo
                       #   as submodule
        src
          class1.java

• still a push to the 'common' Git repo whenever class1.java is modified, and a git submodules update in all other branches/repos that need the new 'common' evolution.