Aleks <oles.slo...@gmail.com> 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
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html