Git submodule management strategy

We use GIT to manage our project.

Each project has a “core” (for example, the structure from which we will build the project). Thus, each project has at least 2 branches of remote objects:

  • 1 repository for this core structure.
  • 1 repository per client project.

We also have modules. Each module has a kernel that contains the main functional function, and we select each module from this base for each client.

  • So, we have submodules that are included in each client project.
  • But I can’t understand how to handle part of the personalization of submodules.

How does GIT help me if I want to add some new files to a submodule that should only be used in one specific client project?

Since thoses files are personalized for the main project, it would be best to commit some files contained within the submodule to the client project branches, but it seems like I cannot, since each submodule is independent.

Ps: We use SmartGit.

+4
source share
2 answers

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

If you made changes to another project in your repository, they may want to merge with your project. This one can use a subtree - it can shift the paths in its tree and then they can only combine the corresponding parts of your tree.

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

The idea of ​​merging a subtree is that you have two projects, and one of the projects is mapped to a subdirectory of the other and vice versa. When you specify a subtree merge, Git is smart enough to realize that the other subtree and the merge respectively are pretty surprising.

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

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

+1
source

I can’t, because each submodule is independent.

Although it is true that the submodule is "independent" because it has its own set of commits and branches as a separate repository, you can still define the client-project branch on the specified submodule.

This branch will be defined in the main client-project repository, as well as in the base submodule, to isolate the changes specific to the client project executed in both repositories.
When you discard the changes that are made in the base submodules, you insert them into the client-project branch, whose name matches the name of the client branch used in the parent repository of your client.

In short, a naming convention can help you isolate small specific changes made to the base submodule used and shared by many client project repositories.

0
source

All Articles