Git submodule management strategy

Question

We use GIT to manage our project.

Each project has a "core" (like a framework from who we'll built the project) So each project has at least 2 remotes branches:

• 1 repository for that core framework.
• 1 repository per client project.

We also have modules. Each module have a core that contain the basic functionnality, and we personnalize each module from that base for each client.

• So we have submodules that are included in each client project
• But I can't figure out how to handle the personnalization part of the submodules.

How can GIT help me if I want to add some new files in a submodule that must be used only in 1 particular client project ?

As thoses files are personnalized for the main project, the best case would be to commit some files contained inside the submodule in the client project branch, but it looks like I can't as each submodule are independent.

Ps.: We use SmartGit.

Answer 1

This is a scenario where you can use git-subtree (merging)

If you made changes to the other project in your repository, they may want to merge from your project. This is possible using subtree — it can shift up the paths in your tree and then they can merge only the relevant parts of your tree.

http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

The idea of the subtree merge is that you have two projects, and one of the projects maps to a subdirectory of the other one and vice versa. When you specify a subtree merge, Git is smart enough to figure out that one is a subtree of the other and merge appropriately — it’s pretty amazing.

http://progit.org/book/ch6-7.html

But I suppose you want to use submodules and not move away from it.

Answer 2

I can't as each submodule are independent.

While it is true a submodule is "independent", since it has its own set of commits and branches as an individual repository, you still can define a client-project branch on said submodule.

That branch would be defined in your main client-project repo, as well as in the core submodule, in order to isolate changes specific to a client project done in both repos.
When you push back those changes done in the core submodules, you push them in a client-project branch whose name matches the name of the client branch used in your client parent repo.

So in short, a naming convention might help you isolate small specific changes done in a core submodule used and shared by many client-project repos.