8

Our team is currently in the process of moving from SVN to Git. We currently use Maven as our build tool.

Currently our projects have a build hierarchy through Maven, but are flat on the file hierarchy/repository side. My goal is to more closely match the Maven build hierarchy and the file structure hierarchy in our repositories in order to make everything easier to understand.

My question is what is the proper level to create Git repos so that the file hierarchy/organization is maintained? Example:

  • Big Project - (no source here, just a pom)
    • Backend Project (source + pom)
    • Clients (no source here, just a pom)
      • Console (source + pom)
      • Web (source + pom)

So the "pom only" project would be used to group actual source projects. But where does the Git repo belong? Some team members are concerned that commits to the Web project don't belong in the history for the Console project. But if the Git repos are at the lowest levels (the leaf nodes of the tree), we lose the file structure organization (even though the build hierarchy can be maintained in Maven).

Edit: The team member's concern wasn't as much with commit history as it was with Tagging. Given that the Git repo root is at the Big Project, and I want to tag the Web project (by tagging the Big Project), why should that tag include the Console project, which maybe not in relevant to the Web tag?

JT703
  • 1,311
  • 4
  • 17
  • 41
  • How did you handles this in SVN? I assume you had a structure like the described. You simple checked out the Big-project and everything else will got on the Hard drive...so why would you like to change this? – khmarbaise Aug 16 '11 at 20:41

2 Answers2

5

I have a maven project consisting of over 60 modules, and my team has discussed the same question of exactly where the git repository roots should be. So far, every discussion has ended with leaving the entire project, all the way up to the root pom, in the same project. The decision is mainly based around developer convenience--we don't have to clone and open multiple different repositories to work in what's essentially the same project. The question of history seems bogus to me. Who cares if the history is blended? You can always see a particular file's/module's/path's history in git, exclusive of any others.

An option we've considered is something called git submodules, which let you embed repos within repos. This could be an option for organizing your hierarchy if you decide to break it up.

Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199
  • +1 for a single project. Unlike Subversion and other, old tools, this isn't a bottleneck. – Aaron Digulla Aug 17 '11 at 15:55
  • What tooling do you use? I have a similar setup, with 20 something maven modules in a single git repository, containing ±800000 lines of code. I got serious performance issues in Eclipse using Egit due to constant reindexing... – Rens Verhage Mar 15 '13 at 13:16
  • We use IntelliJ, which handles it fairly well, especially since version 12, but in the 1.5 years since this question, we've moved toward spinning modules off as their own projects living in their own repos, partly to avoid IDE performance issues. This approach introduces its own set of problems but has other benefits as well. – Ryan Stewart Mar 16 '13 at 15:06
0

I would suggest to leave the structure in Git the same as in SVN which means a single Git repos with the whole project in it. The point is you can use the Maven release plugin without any problems for such kind of multi-modules builds.

khmarbaise
  • 92,914
  • 28
  • 189
  • 235