如何在Git中为具有共享模块的两个项目组织项目? [英] How to organise projects in Git for two projects with shared modules?
问题描述
我现在面临着在Git中组织两个项目代码的挑战.有两个软件A和B，一个可以说B与A相同，只是它具有一些附加模块(更多功能).所以现在的问题是，我有两个项目，但是我不能简单地将它们分成两个存储库，因为它们共享相同文件的4/5. A和B被编译为两个独立的软件版本，那么如何组织它们才有意义?
I am now faced with a challenge of organising two projects' code in Git. There are two software A and B, one could say that B is the same as A, only that it has some additional modules (more features). So the problem now is, I have two projects, but I cannot simply separate them into two repositories since they share 4/5 of the same files. A and B are compiled to be two separate software releases, so how can I organise them such that it makes sense?
我曾经考虑过要有2个存储库，但是如何使它起作用，以便在更改A中的某些内容时，B也会被更新?这在Git中是如何工作的(对不起，我还没有在更高级的水平上使用Git)?如果我可以在不同时编译A的情况下编译B(发布版本)?任何帮助将不胜感激，如果我没有正确描述某些内容，请告诉我.提前非常感谢您.
I have thought about having 2 repositories, but how can I make it work so that when I change something in A, B is also updated? How does this work in Git (sorry I have not used Git at a more advanced level yet)? And if it will be possible for me to compile B (make a release) without compiling A at the same time? Any help would be appreciated, and if I didn't describe something properly please let me know. Thank you so much in advance.
推荐答案
您有几个选择，应该将它们组合使用.
You have a few options, and they should be used in combination.
- 将A和B之间的差异转换为配置选项.
- 提取A和B之间的公共位.
- 将额外的功能提取为模块.
配置可能意味着使用配置标志打开和关闭功能.这也可能意味着为A和B使用单独的模板.A和B成为已保存的配置.这可能最适合主要是表面上的更改，或者对于诸如数据库和API凭据之类的流程相当不可或缺的功能.
Configuration can mean turning features on and off with configuration flags. It can also mean having separate templates for A and B. A and B become saved configurations. This is probably best for changes which are mostly cosmetic, or if the features are fairly integral to the process like database and API credentials.
将其他位提取到模块中将很有意义.允许连接到新数据库或API的子类.
Other bits will make sense to extract into modules. Subclasses allowing connections to new databases or APIs for example.
最初，您可以将所有内容作为单个存储库进行管理. A和B就像存储库中单独的目录一样简单.可能看起来像这样.
Initially you can manage this all as a single repository. A and B could be as simple as separate directories within your repository. It might look like this.
base/
modules/
feature1/
feature2/
releases/
A/
config
templates/
B/
config
templates/
一切都在一个回购中，既简单又方便.最初它会为您服务，可能只是您所需要的.但它鼓励将所有内容紧密地结合在一起.当您只需一次更改所有内容时，为什么还要编写一个经过深思熟虑的API?
Everything in one repo is simple and convenient. It will serve you initially and it might be all you need. But it encourages wielding everything tightly together. Why write a well thought out API when you can just change everything at once?
如果发现需要更多的模块化，则可以将基础，每个模块和每个发行版提取到各自的存储库中.这会带来依赖性管理.
If you find you need more modularity, you'd extract the base, each of the modules, and each of the releases into their own repositories. This brings up dependency management.
Initially, A and B could pull in their dependent base and module repositories as Git Submodules. This will work in the short run, but it's a poor way to manage dependencies and, again, encourages binding things tightly together.
最后，您将每个存储库作为自己的项目分别进行管理.使用您语言的普通系统分发模块(Ruby gem，Javascript npm，Python软件包等)，就像发布任何项目一样进行发行，可能使用私有模块存储库.然后，A和B会使用您语言的依赖系统来进行安装，以选择要安装的其他功能.
Finally you'd manage each repository separately as their own project. Make releases as you would for any project using your language's normal system for distributing modules (Ruby gems, Javascript npm, Python packages, etc...), probably using a private module repository. A and B then become installations using your language's dependency system to choose which extra features to install.
这需要一些实践才能正确执行，对于许多内部项目而言，完整版本和依赖管理是过大的.首先将所有内容重新组织到一个存储库中的子目录中，这可能会很困难，并查看是否需要更多内容.
This takes some practice to get right, and for many internal projects full releases and dependency management is overkill. Start by reorganizing everything into subdirectories in one repository, this will likely be challenge enough, and see if you need more.
这篇关于如何在Git中为具有共享模块的两个项目组织项目?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
