Git repository and Maven project

Can you help to clarify such question. We have 2 different projects. Name of first project say "server". Second - "client". Every project has own maven build structure. Server produces the war archive for deployment. The Client project produces the client jar for testing Server application. Aside from these projects we should store different artefacts like prototypes for developing pages for server project. There are two opinions about approach to arrangement git repository.

1) Create one repository https://git.org/my-project/src
Create 3 separate folders inside of src directory. So we will have such 
structure :
root of repository https://git.org/my-project/src/
contains 2 different maven projects and folder for prototypes files
https://git.org/my-project/src/server
https://git.org/my-project/src/client
https://git.org/my-project/src/prototypes

2)Create for every maven project and prototypes separate repository. https://git.org/my-server/src https://git.org/my-client/src https://git.org/prototypes/src

The root of maven project begins from src folder in every repository ( https://git.org/my-server/src and https://git.org/my-client/src) The xml files and images of prototypes will be inside of https://git.org/prototypes/src I believe the second approach more proper git-approach. Such approach allows team to use such advanced git features like branging, merging, stash etc.

What approach is proper?

Aleks <oles.slosko@gmail.com> writes:

It depends on how tightly coupled the versions of these three "potentially separate but could be combined" pieces you would want to make. Is a particular version of the "server" software meant to work with any random version of "prototypes"? Is a particular version of the "client" software meant to be used to test any random version of "server"?

Having all three in the same repository means you are guaranteed, and more importantly, your developers are *forced* to guarantee, a checkout of a single commit will contain the state of these three pieces that work well together. A commit that changes only the "server" subtree portion, without updating the corresponding assets in "prototypes" hierarchy that are needed to support what was added to the "server" part, would break the entire system, and hopefully your QA procedure can detect and reject it.

Having all three in separate repositories means your developers can be more loose but it may lead to QA nightmare if a proper procedure is arranged around the entire process (which Git is only a small part of).

There is no single "more proper git-approach"; it depends on your requirements, which the above "how tightly coupled?" question is an example of. Branching, merging, etc. are orthogonal and can and will be useful regardless of the repository arrangement you choose.