Modular Java Application on GIT repository

问题

I'm working on a "modular Java application", it has around 60 independent modules, all obviously "buildable" on their own.

I'm trying to understand what can be the best approach to structure this type of application under GIT.

I'll explain better myself:

I've been working several years with SVN and it would be really easy for me to structure a project like this under a centralized version control tool such as SVN, while I'm not sure about the GIT best practices and pros/cons.

With SVN:

I would import all the project under the same repository

I would consider two different approaches, with similar consequences, for example:

 mod_A
   |___trunk
   |___branches
   |   |___branch_A
   |
   |___tags
 mod_B
   |___trunk
   |___branches
   |   |___branch_A
   |   |___branch_B
   |
   |___tags       

OR

 trunk
   |___mod_a
   |___mod_b
   |___mod_c
 branches
   |___branch_A
   |   |___mod_a
   |___branch_B
       |___mod_a
       |___mod_b

With both the approaches it would be really easy for me to achieve information like, which are the modules branched for a particular feature, and see the application from the modules prospective but also from the branches prospective.

Moreover, with both the structures I would be able to easily branch just some of the modules without being forced to branch them all anytime.

With GIT:

At the moment the modular application i'm working with is structured with a single independent repo for any module, in my view this structure, even if brings some advantages, has also a real big issue.

In fact it looks hard for me to have a clear whole overview of the application, cause I've to connect to every single repository and check the branches to understand which modules are involved in a particular branch, so if I've to manage a branched version of my application, that for example involves just 7 modules to be branched in a particular BUG_FIXING or FEATURE branch and not the whole application, I would have no way to get this info through GIT, and I should manage this information in a custom way.

Then even if the application would have been set up within the same repo, i would have been unable to decide to branch just a subset of modules cause "Git operates on the entire repository, not on individual directories".

Can you please clarify how can be the best approach to follow with a modular application, can GIT sub modules be a solution? Is there any other approach i'm not considering, or i'm moving from wrong assumptions?

Thanks a lot!

回答1:

First you should manage the module Java application in one git repo as you managed in one SVN repo, since all the modules are works for the same project.

For the branching module structure for you application, I will suggest manage each module in separate branches(modX), and manage your entire project in master branch.

The work flow can be:

• Manage the project level files in master branch. the structure for master branch as:

  Root (master branch)
     |___... (project level files)
  

• Checkout module branches (such as modA branch, modB branch and modC branch) from master. Deleted the project level files and add files for module in mod_X folder.

  Such as for branch modA, the structure is:

  Root (modA branch)
     |___mod_A (folder)
             |___... (module A level files)
  

• When you finished work for module X, then merge modX branch into master branch.

• After all the modules are finished work (and merged into master), the file structure for master branch should be:

  Root (master branch)
     |___... (project level files)
     |___mod_A (folder)
             |___... (module A level files)
     |___mod_B (folder)
             |___... (module B level files)
     |___mod_C (folder)
             |___... (module C level files)
  

• If you update module X in modX branch, then merge modX branch again into master branch to make sure the application is updated.

• To maintain project-level (application aggregator) files, you can also develop/test/fixbug on develop, feature and hotfix branches:

  1. master branch as the production version for your java application.
  2. develop branch (long living branch which should checkout from master branch) is used for all the developers work on it. When the changed application is build successful (verified), you can merge develop branch into master.
  3. featurebranches are short living branches. If you need to develop new features for your application, you can checkout a feature branch from develop branch. And then the feature is finished, merge feature branch into develop branch to verify your code.
  4. hotfix branches are also short living branches. You can fix bugs on the branches, when the bug(s) is fixed, merge the hotfix branch into develop branch.

  And there has a successful branching model you can refer for managing the project-level (application aggregator) files.

回答2:

Aside: Do not use branches to manage different modules. Branches are to be short lived and ultimately merged back to master when ready for release.

---

If the modules "change/release" together, you could lean towards keeping them in one repo. Though the fact that each module had its own trunk/branches folders in SVN seems to indicate they change separately.

If you're using maven with your java application, it could be setup in one repo as a multi-module project.

If you go with separate repos, you can name your branches similarly (add a ticket number or such like feature/ticket-123-more-cow-bells) so you know a given feature impacts multiple modules/repos.

If you go with separate repos per module, then you could use git sub-modules to glue them back together but that's more of a workaround.

Perhaps also reading about a few different git branching strategies would help you understand how 'git thinks' about branches.

来源：https://stackoverflow.com/questions/47325910/modular-java-application-on-git-repository