3

I have a large closed-source project and from time to time I hire freelancers to work on parts of it.

These freelancers are highly specialized and usually, nothing good will come out of giving them access to the entire project. Some will just freak out at the complexity, others will be slightly confused, while most will at some point waste time looking at stuff that doesn't concern them.

Is there a combination of private repositories, branching, submodules, subtree merges, etc, that I can use so that individual freelancers are only exposed to parts of the project, and yet the owner(me) has a convenient centralized way to perform merges, builds, etc?

I've looked at github, gitorious, and gitlab. I prefer to pay github for a private repo over setting up one of the other two on my own servers. But what's the actual git setup and project structure that would make a GitHub private repo work for the use-case described above?

UPDATE

I'm wondering if I can use git filter-branch for this. Here's what I'm thinking:

I'd setup a private repo on GitHub as my main repository, one containing full history on all branches for the entire project. No one but me would have access to this 1st repo.

Then, whenever a new freelancer is assigned to a task, I'd use git filter-branch to produce a smaller branch (full history of master branch on a smaller set of files) that I then push to a 2nd GitHub private repo, and grant them access.

Now's the tricky part. Is there a way to perform operations between the 1st and 2nd repo that basically treat the 2nd repo as a branch of the 1st? Mostly I'd like to do compares, merges, and rebases across these two repositories. Is it possible?

Alex R
  • 10,320
  • 12
  • 76
  • 145

2 Answers2

0

Passing on couple of threads on StackOverflow. Hope it helps.

From past experience you should keep things simple and mapped when working with Git.

Git does not have branch specific permissions.

A way to restrict Git branch access?

Community
  • 1
  • 1
carlodurso
  • 2,844
  • 4
  • 22
  • 37
0

Given the goal you set, I'm going to assume that your project is actually a collection of smaller projects that can be worked on independently, and therefore have their own lifecycle. In that case, I would recommend creating N repositories, each containing one of these small projects. This way you can easily share at the sub-project level, and manage merges at that level too.

As for yourself, you'd then want to setup a super-project that aggregates all this to form the big picture that only you need to see. Whether you choose to use submodules or subtree merges to implement that is entirely up to you.

Sigma
  • 873
  • 7
  • 12