Multiple Git repositories for each Eclipse project or one Git repository

Question

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.

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

Looking at similar questions such as this suggest one project per repository.

Which approach is best practice and what do people implement?

Solution 1

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.

Solution 2

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.

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.

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.

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.

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.)

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.

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.

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.)

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.

Solution 3

I use 1 repo per project.

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?

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

Solution 4

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.

Solution 5

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

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.

View more solutions

Comments

[Marcin Koziński]

Could you hint at links (or terms at least) about splitting and combining? For example by combinining I assume you might mean submodules (or alternatives), but maybe more? About splitting I haven't heard before, so I am really curious.

[robinst]

By splitting I mean taking one repository and split it into multiple using a one-time conversion, e.g. with git filter-branch --subdirectory-filter. By combining I mean taking multiple repositories and creating one new repository from it with a combined history (again, a one-time conversion), e.g. with stitch-repo script. Combining is harder because the separate histories have to be "weaved" together.

[agelbess]

This answer is truly useful. I would go a bit further and say that if you have made a decision of multiple projects for a single "work", then you should also keep different cycles for the projects. Otherwise, just create a single project. So, create a single project, and if you have the need to split it in the future, split it and create new repositories for each project. Keep the old one for archiving reasons. Keep it simple, keep up.