具有复杂项目结构的 Git/Hg 存储库
目前我们正在使用 SVN（是的，我知道这很遗憾:)）并且我们正在检查迁移到 Git 或 Hg 的可能性。 目前，我们有一个 svn 存储库，其结构如下：
Platform 1-
. Country 1
. Customer A
. Project Z
. Project Y
. Customer B
. Project X
. Country 2
. Customer C
. Project W
Platform 2
. Country 1
等等。
我们只有 2 个顶级“平台”，但国家、客户、特别是项目的数量相当多（我确信项目数量> 100）。 这种结构对我们来说非常方便，因为很容易找到必要的项目（因为开发人员知道平台、国家/地区和客户）。通常开发人员可以在 1 周内多次切换项目，因此这种组织非常重要。
基本用例：
- 工程师收到项目描述（通常有人已经参与该项目）
- 工程师的硬盘上有整个 SVN 存储库副本。他转到必要的国家/客户，并对客户文件夹（如果他没有项目）或项目文件夹（如果他之前已经签出过）进行 SVN 更新。
- 用户处理项目并通过提交整个项目文件夹来提交。
有些人只是浏览TortoiseSVN Repo Browser，找到必要的项目并查看它。
所以现在我们需要一些同样简单但使用 Git/Hg 的东西。据我了解，Git 中非常常见的模式 - 1 Repo/1 Project。所以问题是：
- 有没有办法对 Git/Hg 中的存储库进行分类？
- 有没有办法通过 GUI (Win) 浏览存储库并提取必要的存储库？
- 您对如何使用 Git/Hg 组织我们的存储库有任何建议吗？
我创建了 BitBucket Git 存储库来使用它，但现在还不明白如何组织我们的项目。
只需要注意一点 - 分支对我们来说并不是很常见，因为项目在开发方面相当小。
at the moment we're using SVN (yeah, I know that's shame :)) and we're checking possibility to move for Git or Hg.
At the moment we have one svn repo with structure like that:
Platform 1-
. Country 1
. Customer A
. Project Z
. Project Y
. Customer B
. Project X
. Country 2
. Customer C
. Project W
Platform 2
. Country 1
etc.
We have only 2 top level "Platforms" but number of Countries, Customers and especially projects is pretty high (I'm sure number of projects >100).
This structure is quite handy for us as it is easy to find necessary project (as developer knows Platform, Country and Customer). And as usually developer can switch project few times during 1 week this organization is quite important.
Basic use case:
- Engineer receives project description (quite often someone already worked on the project)
- Engineer has whole SVN repo copy on his HDD. He goes to the necessary Country/Customer and does SVN Update for Customer folder (if he doesn't have project) or Project folder (if he already checked out it before).
- User works on the project and does commits by committing whole Project folder.
Some people just browse through TortoiseSVN Repo Browser, find necessary project and check it out.
So now we need something same simple but with Git/Hg. As I understand in Git the very common pattern - 1 Repo/1 Project. So the questions are:
- Is there any way to categorize repos in Git/Hg?
- Is there way to browse repos throug GUI (Win) and pull necessary one?
- Do you have any offer how to organize our repo using Git/Hg?
I created BitBucket Git repo to play with it but haven't understand now how I can organize our projects.
Just one note - branches isn't very common case for us as projects are quite small in terms of development.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这不仅很常见，而且当您使用 Mercurial 或 Git 等分布式版本控制系统时，它实际上是强制性的。原因是两个系统还不支持窄克隆，即克隆您只下载属于较大存储库中某个子目录的历史记录。因此，您需要检查所有内容只是为了获取存储库的一小部分。
因此，为每个项目创建一个存储库。您可以通过创建像现在这样的文件夹结构来将项目分组。文件夹结构不会出现在任何存储库中——它只是对相关存储库进行分组的一种方式。
Kallithea 等工具还可以让您按层次结构组组织存储库。这将使您的用户以方便的方式浏览存储库。
所以，问题是：
总结上面的答案：是的，您可以组织存储库。您可以通过将它们放入目录结构来在文件系统级别上执行此操作，也可以通过使用合适的存储库管理器在 HTTP 级别上执行此操作。
如何浏览存储库以找到合适的存储库将取决于组织。共享存储库的推荐方式是 HTTP，然后“打开存储库”对话框将不允许您浏览文件夹 - 因为这些文件夹仅存在于 Kallithea 提供的 URL 中。因此，您的工程师通常会在浏览器中浏览存储库结构，然后将正确的 URL 复制粘贴到 TortoiseHg 中。
当他们从服务器克隆时，工程师应该将本地克隆放入与服务器上的克隆相匹配的层次结构中。此层次结构将通过本地磁盘上的目录来完成。然后，他们当然可以像平常一样使用 Windows 资源管理器浏览此层次结构。
It's not just very common, it's practically mandatory when you use a distributed version control system like Mercurial or Git. The reason is that both systems don't support narrow clones yet, that is, clones where you only download the history belonging to a certain subdirectory in the bigger repository. So you need to checkout everything just to get a small part of the repository.
So create one repository for each project. You can organize the projects into groups by creating a folder structure like you have today. The folder structure won't be in any repository — it's just a way to group related repositories.
Tools such as Kallithea will also let your organize repositories in hierarchical groups. This will let your users browse the repositories in a convenient way.
So, the questions were:
To sum up the answer above: Yes, you can organize repositories. You can do it on the file system level by putting them into a directory structure and you can do it on the HTTP level by using a suitable repository manager.
How to browse the repositories to find the right one will depend on the organization. The recommended way to share repositories is HTTP and then the "Open Repository" dialog won't let you browse around in the folders — since the folders only exist in the URLs served by, say, Kallithea. Your engineers will therefore typically browse the repository structure in their browser and then copy-paste the right URL into TortoiseHg.
When they clone from the server, the engineer should then put the local clones into a hierarchy that match the one on the server. This hierarchy will be done with directories on their local disk. They can then of course browse this hierarchy with Windows Explorer like normal.
最简单的选择是您只需为项目使用一个 git 存储库，就像使用 subversion 一样。
优点：和你一样。缺点：要更新任何部分，您需要更新存储库的所有部分；没有像 SVN 那样的“仅在此处”更新。
一般来说，如果平台、国家/地区和项目完全独立，我建议您的工程师在本地创建该结构，然后将存储库命名为
${platform}-${country}-${project}以保留该细节。如果您愿意，您显然可以编写结帐过程来构建该结构，并且您可能会寻找诸如 mr 或其他旨在从单个位置处理多个存储库的工具（如果您愿意）。
另一方面，如果您的项目非常相似，您可能会查看分支，也许还有 git rebase 驱动的工作流程，这可能会让您更轻松地将常见更改合并到系统中。
The simplest option is that you simple use one git repository for the project, just like you do with subversion.
Advantage: just the same as you have. Drawback: to update any part you update all parts of the repository; there is no "only here" update like SVN.
Generally, if the platform, country, and project are entirely independent I would suggest your engineers just create that structure locally, and you name your repositories
${platform}-${country}-${project}to preserve that detail.You can obviously script the checkout process to build up that structure, if you wish, and you might look to tools like mr or other tools designed to handle multiple repositories from a single location, if you wish.
On the other hand, if your projects are very similar you might look at branches, and perhaps a
git rebasedriven workflow, which will probably make it easier to merge common changes into your system.是的，这是很常见的，强烈建议每个项目都有一个存储库（Git / Hg 中的存储库比 SVN 中的存储库更轻量级）。这样一来，只需要签出（克隆）一个项目的人就可以这样做。否则，每个人都必须克隆整套项目。然而，想要一切的人，就必须一一克隆。因此，如果您不打算拥有分支，则可以将所有项目放在一个存储库中（因为如果您将它们全部放在一起，则分支不能在项目级别，因此如果您要分支，则每个项目存储库都是必要的。
）基于文件夹，以便 URL 将显示分类，例如
[email protected]/platform1/Country1/CustomerA/project1.git等。请注意，如果您的项目位于单个存储库中，您将无法来获取这样一个URL。您将只有[email protected]/repo.git< /code> 或类似的东西。查看权衡并决定是一个存储库还是多个存储库。您甚至可能想按平台等而不是项目进行分组。
您可以使用 GitWeb 或 cgit 等 Web 界面来浏览存储库。
Yes, it is very common and highly recommended to have a repo per project ( repos are more lightweight in Git / Hg than in SVN). This is so that people who need to checkout (clone) only one project can do so . Otherwise, everyone will have to clone the entire set of projects. However, people who want everything, will have to clone one-by-one. So if you aren't looking at having branches, you can have all the projects in one repo ( as branching cannot be at project level if you have them all together and hence per project repo will be necessary if you were branching.)
Categorize repos based on the folder so that the URL will show the categorization like
[email protected]/platform1/Country1/CustomerA/project1.gitetc. Note that if you have the projects in a single repo, you will not be able to get such a URL. You will only have[email protected]/repo.gitor something like that.See the tradeoffs and decide or one repo or multiple repos. You may even want to group by platform etc. rather than projects.
You can use web interface like GitWeb or cgit to browse repos.
您需要每个项目一个存储库。这可以减少处理项目时需要保留在本地的数据量：与 SVN 不同，您拥有每个存储库副本中每次更改的完整历史记录。在执行 git log 时，它还可以防止一个项目的提交与另一个项目的提交混杂在一起。
然后添加一个顶级存储库来处理您的顶级结构。在该存储库中，您为每个叶存储库添加 git 子模块。人们总是开始克隆/拉取顶层结构，然后只使用 git submodule update 和 git pull 来检查他们需要的项目。
顶级项目将跟踪子模块的头部哈希值，您可以根据您的喜好使用或不使用这些子模块。
You want one repo per project. This keeps down the amount of data you need to keep local when working on a project lower: unlike SVN, you have the complete history of every change in every repo copy. It also keeps commits on one project from getting interspersed with commits from another project when doing
git logs.Then you add a top level repo to handle your top level structure. In that repo, you add git submodules for each of the leaf repos. People always start cloning/pulling the top level structure then only check out the projects they need with
git submodule updateandgit pullfor the projects.The top level project will track the head hashes of the submodules which you can use or not depending on your preference.