每个 Eclipse 项目或一个 Git 存储库的多个 Git 存储库

Multiple Git repositories for each Eclipse project or one Git repository

提问by Codey McCodeface

I am in the process of moving to Git from SVN. In SVN I had multiple eclipse projects in a single SVN repository that is convenient for browsing projects. I was going to move to having one git repository per eclipse project but EGit suggests doing otherwise.

我正在从 SVN 迁移到 Git。在 SVN 中，我在单个 SVN 存储库中有多个 Eclipse 项目，以便于浏览项目。我打算让每个 eclipse 项目有一个 git 存储库，但 EGit 建议不要这样做。

The guide for EGitsuggests putting multiple projects into a single Git repository.

EGit指南建议将多个项目放入单个 Git 存储库。

Looking at similar questions such as thissuggest one project per repository.

查看诸如此类的类似问题建议每个存储库一个项目。

Which approach is best practice and what do people implement?

哪种方法是最佳实践，人们实施什么？

回答by robinst

It depends on how closely-related these projects are. Ask yourself the following questions:

这取决于这些项目的紧密程度。问自己以下问题：

• Will they always need to be branched/tagged together?
• Will you want to commit over all projects, or does a commit mostly only touch one project?
• Does the build system operate on all of them or do they have a boundary there?

• 它们是否总是需要分支/标记在一起？
• 您想提交所有项目，还是一次提交主要只涉及一个项目？
• 构建系统是对所有这些都运行还是在那里有边界？

If you put them all in one, some things from above will be easier. You will only have to branch/tag/stash/commit in one repository, as opposed to doing it for every repository separately.

如果你把它们放在一起，上面的一些事情会更容易。您只需在一个存储库中进行分支/标记/存储/提交，而不是分别为每个存储库执行此操作。

But if you need to have e.g. separate release cycles for the projects, then it's necessary to have each project in an independent repository.

但是，如果您需要为项目设置单独的发布周期，那么就必须将每个项目放在一个独立的存储库中。

Note that you can always split up a repository later, or combine multiple repositories into one again without losing history.

请注意，您可以随时拆分存储库，或将多个存储库再次合并为一个，而不会丢失历史记录。

Combining is a bit harder to do than splitting, so I would go for one repository first and see how it goes.

合并比拆分更难做，所以我会先去一个存储库，看看它是如何进行的。

回答by Peter van der Does

I use 1 repo per project.

我每个项目使用 1 个 repo。

Some reasoning:

一些推理：

• When you discover you messed up something after several commits, it's much easier to fix when it's just one project. Just think about, you did commits to two other projects and now you need to fix the commit you did on the 3rd project.

• As Fedir said, your history and log is much cleaner. It only shows the commits for that project.

• It works better with the development workflow I have. I have a master branch for production, develop branch for, well, development, and I create branches to implement features (you can read more about it here: http://blog.avirtualhome.com/development-workflow-using-git/)

• When you work in a team, and so "share" the git repo, do the team members really need all the other projects as well?

• 当你发现你在多次提交后搞砸了一些东西时，当它只是一个项目时更容易修复。试想一下，您确实提交了另外两个项目，现在您需要修复您在第三个项目中所做的提交。

• 正如 Fedir 所说，您的历史记录和日志要干净得多。它只显示该项目的提交。

• 它与我拥有的开发工作流程配合得更好。我有一个用于生产的 master 分支，以及用于开发的开发分支，并且我创建了分支来实现功能（您可以在此处阅读更多相关信息：http: //blog.avirtualhome.com/development-workflow-using-git/)

• 当你在一个团队中工作并“共享”git repo 时，团队成员真的也需要所有其他项目吗？

Just a few thoughts, but what it boils down to: Do what works for you.

只是一些想法，但归结为：做对你有用的事情。

回答by Danny Remington - OMS

I have multiple projects (Eclipse projects) and have tried different things to find out what worked best in terms of actual daily development. Here is what I found and I think that most people would find the same thing if they kept track of the results and analyzed the results objectively.

我有多个项目（Eclipse 项目）并尝试了不同的方法来找出在实际日常开发中最有效的方法。这是我的发现，我认为如果大多数人跟踪结果并客观地分析结果，他们会发现同样的事情。

In short applying the following rules will give the best results:

简而言之，应用以下规则将得到最好的结果：

1. Make a separate repository for each project group.
2. Each project group consist of a group of projects that are tightly connected to each other, that should be administered together and that cannot be easily decoupled from each other.
3. A project group can contain a single project.
4. A project group that contains multiple projects should be examined to see if some of its projects can be decoupled from each other so it can be split into smaller project groups that are still contain projects that are tightly connected to each other, that should be administered together and that cannot be easily decoupled from each other.

1. 为每个项目组创建一个单独的存储库。
2. 每个项目组由一组彼此紧密相连的项目组成，这些项目应该一起管理，并且不能轻易地相互分离。
3. 一个项目组可以包含一个项目。
4. 应该检查包含多个项目的项目组，看看它的某些项目是否可以相互解耦，以便将其拆分为较小的项目组，这些项目组仍然包含彼此紧密连接的项目，应该一起管理并且不能轻易地相互分离。

The following guidelines explain this process for determining which projects to put in the same repository in more detail:

以下指南更详细地解释了确定将哪些项目放入同一存储库的过程：

1. If a project is not closely connected to any other project (for example, the project can be opened without other projects being opened and no other projects relies on the project being opened when they are opened) then you should definitely place it in its own repository for the reasons explained in the answers above this one.

2. If a project is dependent upon other projects or other projects depend upon the project then it comes down to exactly how connected are they upon each other, how well they can be packaged together and how easily can they be decoupled from each other.

1. 如果一个项目与任何其他项目没有紧密联系（例如，该项目可以在不打开其他项目的情况下打开，并且没有其他项目依赖于打开时打开的项目）那么你一定要把它放在自己的存储库中原因在上面的答案中解释了这一点。

2. 如果一个项目依赖于其他项目或其他项目依赖于该项目，那么这归结为它们彼此之间的联系究竟如何，它们可以打包在一起的程度以及它们彼此分离的难易程度。

A) For example a testing project that contains junit test classes to test the classes of a main project is a case where the two projects are very connected with each other, can easily be packaged together and cannot be easily decoupled from each other. These projects should be placed in the same repository for the reasons explained in part C below.

A）例如一个包含junit测试类的测试项目来测试一个主项目的类是两个项目相互联系非常紧密的情况，可以很容易地打包在一起，不能轻易地相互解耦。出于以下 C 部分中解释的原因，这些项目应该放在同一个存储库中。

B) In a case where one project relies on another project to provide some sort of shared resources it really comes down to how well that they can be administered together and how easily that they can be decoupled from each other. For example if the project with the shared resources is relied upon by many projects, then it should be put in its own repository because the other unrelated projects are impacted by changes to the shared source code project. In a case like this, the shared resources project should be decoupled from the dependent projects instead of being directly connected to the dependent projects. (For example, it would be better to create versioned archive files [Jar files with a name like "projectName".1.0.1.0.jar for example] and include a copy of those in each project instead of sharing the resources by linking the projects together.)

B) 在一个项目依赖另一个项目提供某种共享资源的情况下，这实际上归结为它们可以一起管理的程度以及它们彼此分离的容易程度。例如，如果共享资源的项目被许多项目所依赖，那么它应该放在自己的存储库中，因为其他不相关的项目会受到共享源代码项目更改的影响。在这种情况下，共享资源项目应该与依赖项目解耦，而不是直接连接到依赖项目。（例如，最好创建版本化存档文件 [名称类似于“projectName”.1.0.1.0 的 Jar 文件。

C) If the multiple projects are connected, can be easily administered together but cannot be easily decoupled from each other, then it depends upon how tightly connected they are with each other.

C) 如果多个项目是相互联系的，可以很容易地一起管理，但不能轻易地相互分离，那么这取决于它们之间的联系有多紧密。

I) If the projects are put into one repository, then the projects will be kept in sync with each other in the repository each time there is a commit, which can be a real life saver if the projects are tightly connected. However, this also creates the issues noted in the answers above this one.

I) 如果将项目放在一个存储库中，那么每次提交时，存储库中的项目将保持同步，如果项目紧密连接，这可以成为真正的救星。但是，这也会产生上述答案中提到的问题。

II) If the projects are put into separate repositories, then you will have to take care to keep there commits in sync with each other and be sure to include some sort of mechanism to indicate which commits belong to the same sync point across the projects (Perhaps something like including the same sync point number in the comments for the commit of each project when a group of commits is done across the projects.)

II）如果项目被放入单独的存储库，那么您必须注意保持提交彼此同步，并确保包含某种机制来指示哪些提交属于跨项目的同一同步点（也许是在跨项目完成一组提交时，在每个项目的提交的注释中包含相同的同步点编号。）

III) So in cases like this, it is almost always better to put these projects together into a single repository to reduce the overhead of human effort in syncing the commits and to avoid human error should the commits need to be backed out. The only time that it might be better to place them in separate repositories is when only one of the projects is being changed regularly and the other connected projects are rarely changed.

III) 因此，在这种情况下，将这些项目放在一个存储库中几乎总是更好，以减少同步提交的人力开销，并在需要撤回提交时避免人为错误。将它们放在单独的存储库中可能更好的唯一时间是只有一个项目定期更改而其他连接的项目很少更改。

回答by Matthew Kemnetz

I think this question is related to one I answered here. basically Git by its nature supports a very fine granular structure when it comes to projects/repositories. I have read and been taught that 1 repository per project is almost always best practice. You lose almost nothing by keeping the projects separate and gain a lot as other have been describing.

我认为这个问题与我在这里回答的问题有关。基本上，当涉及到项目/存储库时，Git 本质上支持非常精细的粒度结构。我已经阅读并被教导每个项目 1 个存储库几乎总是最佳实践。通过将项目分开，您几乎不会失去任何东西，而正如其他人所描述的那样，您会获得很多。

回答by Fedir RYKHTIK

Probably, it will be more performant to work with if You will create multiple git repositories.

如果您将创建多个 git 存储库，可能会更高效。

If You will make a branch, only project's files would be branched, and not all the projects. Small project it will be faster to analyze, to commit. Operations will take less of time.

如果您要创建分支，则只会分支项目的文件，而不是所有项目。小项目分析、提交会更快。操作将花费更少的时间。

The log will be more clear also, You could make more granulated configuration if You will have multiple git repositories.

日志也会更清晰，如果您有多个 git 存储库，您可以进行更细化的配置。