On Wed, 20 Nov 2013 05:51:53 -0800 (PST)
> I want to use for several programmer as a team. I thought of this
> The team member should be able to read and write on the baselib but
> user1 should only see:
> and user2 should see:
> As I understand GIT (beanstalk) every user can see ALL branches so I
> can not use branches.
With plain Git, yes.
But there exists various server-side front-ends (gitolite, gitosis etc)
or "turn-key" solutions not based on Git (gitblit, gitlab etc) which
provide virtualized Git users and per-branch access controls.
> How is it possible to manage different subprojects in one project
> with different programmer teams and GIT?
Using a front-end armed with access rules is one solution.
But if by "beanstalk" you mean  then "it" looks like a front-end
already so consult their docs/ask their support about whether access
controls are possible, and if yes, then what they allow you to control.
I'm also afraid you're coming from Subversion and hence you naturally
confuse filesystem paths and branches; contrary to Subversion, in Git
these concepts are completely orthogonal, and you can't have access
controls on filesystem paths Git happens to store in its repositories.
If this is your case, then make yourself comfortable with this fact and
Using submodules is another solution, requiring nothing but plain Git:
you set up three repos: one for baselib, one for module1 and one for
module2. You then make baselib a submodule of module1 and module2
repos. Then you make sure only user1 has read access to the baselib
repo and full access to the module1 repo, and user2 has read access to
the baselib repo and full access to the module2 repo. This is
typically done by using file-system access controls or front-end
Another approach, which may be "more Git" than those explained above,
is to just dump this access control crap completely and use several
repos instead of a single one. "A team member" maintains a repo in
which they implement baselib. user1 and user2 maintain their own
separate repos in which they maintain module1 and module2. They
periodically subtree-merge  baselib from the team member's repo.
Someone else maintains an integration repo, in which they periodically
integrate stuff from baselib, module1 and module2 -- for instance,
using that same subtree merging technique.
Yet another approach is to just have a repo which can be read and
written by anyone and perform history reviews: if someone messes up
a "foreign" part of the repo, these changes are easy to roll back and
the developer is easy to be punished. I mean, people often tend to
seek for heavyweight technical solutions to mostly social problems
where a mere policy might serve quite well, and possible problems are
rare and are not so hard to fix.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.