Project Organization using Maven + Git

Question

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?

Answer 1

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.