具有多个项目的服务器的GIT存储库布局 [英] GIT repository layout for server with multiple projects

问题描述

我喜欢Subversion设置的方式之一是我可以拥有一个包含多个项目的主存储库。当我想在一个项目上工作时，我可以看看那个项目。像这样

  \main 
 \ProductA 
 \ProductB 
 \Shared 
  

然后

  svn checkout http：//.../main/ProductA 
  

作为新用户在参与特定工作流程之前，我希望在现场探索一些最佳实践。从目前为止我读到的，git将所有内容都存储在项目树根目录下的一个.git文件夹中。所以我可以做两件事之一。
$ b

1. 为每个产品设置一个单独的项目。


2. 设置一个大型项目并将产品存储在子文件夹中。

产品之间存在依赖关系，因此单个大型项目似乎适当。我们将使用所有开发人员可以共享代码的服务器。我已经通过SSH& HTTP和我喜欢的那部分。但是，SVN中的存储库已经有很多GB，所以在每台计算机上拖放整个存储库似乎都是一个糟糕的主意 - 尤其是因为我们因为网络带宽过高而付费。

我可以想象Linux内核项目库同样大，所以必须有一个正确的方式来处理这个与Git，但我还没有弄明白。

对于使用非常大型的多项目存储库是否有任何指导方针或最佳实践？ 解决方案

准则很简单，关于 Git限制 ：
$ b

• 每个项目一个回购


• 一个包含
  

$ b $ b

这个想法并不是永远不会存储你可以在一个巨大的git仓库中建立一个小的仓库，作为一个主要项目建立一个小型仓库，它将引用其他仓库的正确提交，每个仓库都代表一个项目或它自己的共同组成部分。

---

保罗亚历山大 < a href =https://stackoverflow.com/questions/2732020/git-repository-layout-for-server-with-multiple-projects/2732038#comment2760525_2732038>评论：

这听起来类似于subversion提供的外部支持。

我们尝试过这种方式，发现它经常更新版本引用非常麻烦外部因为项目是相互依存而同时开发的。是否有另一种选择？

@Paul：是的，不是从主项目更新版本，而是：

• 直接从主项目中开发您的子项目（如子模块的真实性），


• ，或者您在子回购中引用原始同样的子回购正在其他地方发展：从那里你只需从这个子回购中取消其他地方所做的改变。

在这两种情况下，您都不得不提交主项目来记录新配置。没有外部属性在这里更新。所有的过程都更加自然。

老实说，这听起来像是一种真正的痛苦，任何需要开发人员每次都要手动执行某些操作的东西只是成为错误维护的常规来源。

我想我会考虑使用超级项目中的一些脚本来自动执行此操作。

我回覆：

老实说，你可能是对的。 。直到最新的 Git release 1.7.1 < a>。

git diff 和 git status 都学会考虑子模块状态甚至如果从主项目执行。

您完全不能错过子模块修改。

这就是说：

• 子模块与SVN外部模块不同：请参阅为什么git子模块与svn externals不兼容？


• 管理子模块可能会非常棘手：请参阅 git submodule究竟是如何工作的？。

>

One of the things I like about the way I have Subversion set up is that I can have a single main repository with multiple projects. When I want to work on a project I can check out just that project. Like this

\main
    \ProductA
    \ProductB
    \Shared

then

svn checkout http://.../main/ProductA

As a new user to git I want to explore a bit of best practice in the field before committing to a specific workflow. From what I've read so far, git stores everything in a single .git folder at the root of the project tree. So I could do one of two things.

1. Set up a separate project for each Product.
2. Set up a single massive project and store products in sub folders.

There are dependencies between the products, so the single massive project seems appropriate. We'll be using a server where all the developers can share their code. I've already got this working over SSH & HTTP and that part I love. However, the repositories in SVN are already many GB in size so dragging around the entire repository on each machine seems like a bad idea - especially since we're billed for excessive network bandwidth.

I'd imagine that the Linux kernel project repositories are equally large so there must be a proper way of handling this with Git but I just haven't figured it out yet.

Are there any guidelines or best practices for working with very large multi-project repositories?

解决方案

The guideline is simple, in regards to Git limits:

• one repo per project
• a main project with submodules.

The idea is not to store everything in one giant git repo, but build a small repo as a main project, which will reference the right commits of other repos, each one representing a project or common component of its own.

---

The OP Paul Alexander comments:

This sounds similar to the "externals" support provided by subversion.
We tried this and found it extremely cumbersome to constantly update the version references in the externals since the projects are developed concurrently with dependencies on each other. Is there another option??

@Paul: yes, instead of updating the version from the main project, you either:

• develop your subprojects directly from within the main project (as explained in "True Nature of submodules"),
• or you reference in a sub-repo an origin towards the same sub-repo being developed elsewhere: from there you just have to pull from that sub-repo the changes made elsewhere.

In both case, you have to not forget to commit the main project, to record the new configuration. No "external" property to update here. The all process is much more natural.

Honestly, this sounds like a real pain and anything that requires developers to do something manually each time is just going to be a regular source of bugs an maintenance.
I suppose I'll look into automating this with some scripts in the super project.

I replied:

Honestly, you may have been right... that is until latest Git release 1.7.1.
git diff and git status both learned to take into account submodules states even if executed from the main project.
You simply cannot miss submodule modification.

That being said:

• submodules are different from SVN externals: see "Why are git submodules incompatible with svn externals?"
• managing submodules can be tricky: see "How exactly does git submodule work?".

这篇关于具有多个项目的服务器的GIT存储库布局的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！