CODEWITHSUNDEEP
gitversion-control
Guido
Guido

Reputation: 887

Git: best approach for a single project composed by multiple sub projects?

Introduction I’m wondering which can be the best strategy for configuring Git for a single project composed by several subprojects, where some of them are shared and others are independent but some of them can depend on the shared ones, as in the following scenario where the project is a REST Client/Server architecture with an API server and multiple clients:

 /MyProject       
      |___ /DB_sql
      |___ /APIServer_php
      |___ /WebClient_jvs
      |___ /AppClient_iOS
      |___ /AppClient_Android

The development environment consists of a Git server, one or more developer workstation where the code is developed and tested, and a stage server that runs the api server and db:

                  GIT REPO SERVER
       _________________|________________
      /                                  \
  DEVELOPER(s)                          STAGE
 WORKSTATION(s)                         SERVER
      |                                   |
 /MyProject                          /MyProject
      |___ /DB_sql                        |___ /DB_sql
      |___ /APIServer_php                 |       |___ .git
      |___ /WebClient_jscript             |       |___ (sub project files)
      |___ /AppClient_iOS                 |
      |___ /AppClient_Android             |___ /APIServer_php
                                                   |___ .git
                                                   |___ (sub project files)

Every client is developed individually for every platform, but it cannot be tested without the server, and the server is incrementally developed, testing the usability of its new functions on the client(s), so they are both incrementally developed too, sometimes in distinct times sometimes in parallel. There are many different stages that have to be tracked trough version control. Every single sub project must to have his own track history, but it is also useful to have coupled track history (for example when a new function is developed and tested both on the api server and on a specific client), and of course a full project history, for tracking releases. The apiserver code can be modified both on the developer station or on the stage server.

As far I know, there could be three different ways to setting up git for this kind of matter:

Single .git with multiple sub branching Having just a single .git in the master folder and branching per topics and/or platform, as in

 /MyProject 
      |___ .git      
      |___ /DB_sql
      |___ /APIServer_php
      |___ /WebClient_jscript
      |___ /AppClient_iOS
      |___ /AppClient_Android

but this way it is not possible update the code for the ApiServer on the stage server without download also the clients code, that of course is unnecessary and undesirable, and it is easy to mess up things when have different sub branches for different topics in different sub projects.

Multiple .git Another approach is to git init every subproject directories, as in

 /MyProject 
      |___ .git      
      |___ /DB_sql
      |              |___ .git
      |              |___ (sub project files)
      |
      |___ /APIServer_php
      |              |___ .git
      |              |___ (sub project files)
      |
      |___ /WebClient_jscript
      |              |___ .git
      |              |___ (sub project files)
      |
      |___ /AppClient_iOS
      |              |___ .git
      |              |___ (sub project files)
      |
      |___ /AppClient_Android
                     |___ .git
                     |___ (sub project files)

so to have distinct histories, but this way we loose the ability to track, for example when a new functionality is added both to the server and to a client, because if we do a git commit inside a subproject directory, the master folder git cannot see anymore the changes.

Multiple Single .git approach with Submodules I’ve not tries it yet, so I’m not sure of which are the pitfalls.

Question I don’t know which of the above approach is preferable or if exist some other one, but as the server/clients development cycle is rather typical, I think that out there there are some best practices to be known. On StackOverflow I've found some other questions regarding multiple project, but no one explain in details which is the preferred strategy and why.

Can you describe your preferred way to manage the described scenario, which is the user task flow and how exactly to implement it using Git?

Upvotes: 4

Views: 2564

Answers (1)

Marina Liu
Marina Liu

Reputation: 38096

Single .git of sub branching with a submodule is more suitable for your situation. Let’s see the reason below:

Multiple .git means multiple repositories. A project managed by multiple repositories is not a good idea, and just as you said, it can loose the ability to track.

Why sub branching? You can create different branches based on different workstations, so that the developers can work in parallel. And it can update the stage server if you treat it as a submodule. You can add the submodule by git submodule add <URL for stage server>. If you want to make changes and push them to stage server. You just need cd submoduleFolder and git commit -am 'change for stage server' and git push.

There is one thing you need to notice: git status after you use stage server as a submodule. Assume in master branch, you update the submodule (stage server). You can cd submodulefolder, and then commit&push the changes to stage server. But outside the submodule folder cd.., you can also commit to record the submodule’s update (use git status you will find it’s changes not staged for commit) in the developer workstation. But if you forget to commit and you want to switch to another branch, if there has changes not staged for commit, git will stop you to switch other branches. But it’s not for submodule, if there has changes not staged for commit from a submodule, you can still switch to other branches. So this is the thing you should know, and often use git status can keep you clear-headed.

More about submodule you can refer submodules.

Upvotes: 3

Related Questions