4

They need to collaborate on one folder; they should not see the rest.

They would need to be able to merge their changes into the main code base and get updates from that folder.

This is all based on Windows OS with Atlassian Stash and Git on internal network.

Improve this question
1
  • Are you sure you want them to be not able to read? This means that it cannot be the same repository (including fork), you have to rewrite it or start the directory history again. Commented Oct 3, 2015 at 11:42

2 Answers 2

Reset to default
4

That would mean that one folder needs to be its own repo:

  • added as a submodule (tracking a branch) in the main Git repo
  • forked by the second team, for them to push to the fork and make PR or synchronize from the original folder git repo.
Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Thanks for the reply and the links. I see Submodules are considered a bit complicated solution, I wonder if there are other options that could be simple? I’ve read few posts on people moving to Subtree instead. Wonder if it is suitable, e.g. able to provide separation of access and what are pros / cons. Also, I got lost on forking, isn’t it a complete copy of a repository?
@Rod submodules have improved lately. And fork is a way to make sure the second team cannot push/merge anything on that submodule without the first team's review and approval: stackoverflow.com/a/6286877/6309
Since you are using Stash or however they name it now, note that it does not support server-side merges of submodules, and Atlassian refused to fix it , so you would need to merge any concurrent update of submodule locally. Though, separated project which I suggested in my answer also would not support concurrent update with seamless merging.
@VonC I believe forking is good for public repositories where write access is limited. In this case branching model is in use meaning changes are integrated through Pull Requests, so no need for forks. But I got idea on submodules, thanks for suggestion, have you had successful use of them in a similar case?
@Rod I have used fork in a non-public context before. Combined with submodules, they offera very good isolation.
1

I would suggest separating the subset into a sub-project, and use language-specific ways to deliver it during building of you main project. For example, if you use MS Visual Studio, you could turn it into library or module and use nuget to deliver it during build of your main project.

In my experience it appears to be much more convenient than using submodules, when it comes to merging.

Another reason to do that - and maybe even more important one - that the other team would be able to handle the project as a compilable and testable unit, instead of a pile of source files.

Improve this answer

2 Comments

So that folder with code will move to a completely separate repository in git? Or, if not, how will access separation work?
Yes. Completely separated project with completely separated repository.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.