具有相同GIT主控的多个项目 [英] Multiple projects with same GIT master

问题描述

在我们的开发环境中，我们有一个定制的框架。尽管我们所有的项目都是从基础开始的，但是它通过项目基础使用插件和主题来扩展项目。

文件夹结构为：

• 核心（包含所有项目之间的共享代码）


• 插件（每个子文件夹都是插件，项目，一些项目是特定的）


• 主题（仅包含项目特定的唯一代码）
  

目前我们克隆我们的主资料库删除.git文件夹，创建一个新的资料库并进行我们的更改。
如果项目或主要仓库中的功能或错误得到解决，我们目前手动合并具有各种差异工具（主要是winmerge）的更改，以确保项目特定的主题或插件不会进入主仓库和所有项目都有最新的核心和共享插件。

我知道必须有更好的方法来使用子模块吗？
核心作为子模块，每个插件作为子模块，每个主题作为子模块？
然后每个项目都是自己的回购？

或者是结构不是最适合这种设置的？

解决方案

在一个名为PROJECT的git仓库中使用名为PLUGIN的插件的子模块允许此仓库指向特定版本的插件。因此，如果插件在自己的回购版中进化，PROJET的开发者将不得不进入PROJECT回购的插件目录并发行一个

  git pull 
  

就可以得到它。在开发稳定版本的插件时，它可能是有用的。

此外，该插件的源历史记录只能在自己的回购库中进行管理。这是一个易于理解的开发方案。

使用子模块在使用包含二进制/数据使用集的repo时也很有用，并且具有严格的历史管理。所以它不会减慢你的其他回购。

In our development environment we have a custom framework. While all our projects start with the base it is extended on a project by project base with the use of plugins and themes.

The folder structure is:

• core (Contains shared code between all projects)
• plugins (Each subfolders of is a plugin, some exist in all projects, some are project specific)
• themes (Contains project specific only code)

Currently we clone our master repo delete the .git folder, create a new repo and go about our changes. If a feature or bug is fixed in a project or the main repo, we currently manually merge changes with various diff tools (winmerge mainly) to ensure that project specific themes or plugins don't get in to the master repo and that all project have the latest core and shared plugins.

I know there must be a better approach to this, using sub modules perhaps? core as a sub module, each plugin as a sub module and each theme as a sub module? Then each project being its own repo?

Or is the structure not the best for this setup?

解决方案

Use of a sub module named PLUGIN for plugin in a git repo named PROJECT allow that this repos point to a specific version of the plugin. So if the plugin evolve in its own repos, the developer of PROJET will have to go in the plugin directory in PROJECT repo and issue a

git pull

to get it. It can be usefull to work only with stable version of plugins, while they're developed.

Furthermore the source history of the plugin is only managed in its own repo. It's a development scheme easier to understand.

Use submodule is also usefull when you have repo containing use sets of binary/data, with heavy history management. So it won't slow down your other repos.

这篇关于具有相同GIT主控的多个项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！