Git子模块管理策略
我们使用 GIT 来管理我们的项目。
每个项目都有一个“核心”（就像我们将构建项目的框架），因此每个项目至少有 2 个远程分支：
- 1 个用于该核心框架的存储库。
- 每个客户项目 1 个存储库。
我们也有模块。每个模块都有一个包含基本功能的核心，我们从该基础为每个客户个性化每个模块。
- 因此，我们在每个客户端项目中都包含子模块
- ，但我不知道如何处理子模块的个性化部分。
如果我想在只能在 1 个特定客户端项目中使用的子模块中添加一些新文件，GIT 如何帮助我？
由于这些文件是针对主项目进行个性化的，最好的情况是提交客户端项目分支中子模块内包含的一些文件，但看起来我不能，因为每个子模块都是独立的。
PS：我们使用SmartGit。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个可以使用 git-subtree （合并）的场景
http://www.kernel.org /pub/software/scm/git/docs/howto/using-merge-subtree.html
http://progit.org/book/ch6-7.html
但我想你想要使用子模块而不是放弃它。
This is a scenario where you can use git-subtree (merging)
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
http://progit.org/book/ch6-7.html
But I suppose you want to use submodules and not move away from it.
虽然子模块确实是“独立的”，但由于它有自己的一组提交和分支作为单独的存储库，因此您仍然可以在所述子模块上定义客户端项目分支。
该分支将在您的主客户端项目存储库以及核心子模块中定义，以便隔离两个存储库中完成的特定于客户端项目的更改。
当您推回在核心子模块中完成的那些更改时，您会将它们推送到客户端项目分支中，该分支的名称与客户端父存储库中使用的客户端分支的名称相匹配。
简而言之，命名约定可以帮助您隔离在许多客户端项目存储库使用和共享的核心子模块中所做的小的特定更改。
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.