Multiple streams over single project in Git?

1.3k views Asked by At

I went through blog regarding Git best practices model. As we are going to make Git as our major head for SCM for the upcoming projects in our organization, I have some doubts, regarding them not able to find much over internet.

Our project architecture is: We have only one Main-Project and in this project we have 8-10 sub-projects say SP1, SP2 ... SP8. All these projects are owned by their individual group members and they have nothing to do with any other Sub-Project.
We also want to have one Master Branch one Testing branch and one Release Branch for our Main-Project.

First: If we follow this scenario then while cloning everyone should get all MainProject by Git but group members don't want any other subprojects. How do we achieve this by Git? Is there any stream like concept in Git?

Second: How can we set user authentication permission for Sub-Projects, So that no other SubProject member can pull, push or clone to other Sub-Projects.

Are these things possible in Git?

2

There are 2 answers

2
VonC On BEST ANSWER

"stream-like concept"? I saw those in ClearCase or RTC (Rational Team Concert).

No there is no stream, where you could define the list of "components" you want to work with.

But there are branches: in each branches you can add or remove the submodules you need to see or to ignore. See "How do I remove a Git submodule?"

So you could achieve a similar configuration as in streams, with branches including only the submodules you need.

Regarding the ACL (Access Control List), the most complete solution is gitolite, a perl script called by your Git server (apache or ssh, which are doing the authentication), and which will do the authorisation.

0
David Deutsch On

My suggestion would be to keep each "subproject" in its own Git repository. They have nothing to do with each other, have separate authentication requirements, etc. In addition, keeping separate codebases in a single repository can result in a lot of spurious merge commits, where one side of the merge is a change to project A and the other side is a change to project B, creating a lot of noise.