Aleks <oles.slosko@xxxxxxxxx> writes: > 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. 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). > I believe the second approach more proper git-approach. > Such approach allows team to use such advanced git features like > branging, merging, stash etc. 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html