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 ever开发者_StackOverflow社区ything 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?
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.
精彩评论