Managing GIT forks

Question

Another noob question from a Git newbie.

I have a git repo, with two devs working on two different forks. The requirements were that everyone should be able to work independently and after some changes both would create a pull request and I would merge their work into main repo. When this has happened, both will pull in the changes from the main repo (by adding it as remote) and continue working on latest code.

My questions-

1. Is this a good approach to follow?
2. Should I create branches for each of the devs and ask them to commit in their own branches and later merge into master? (looks like overhead to me)
3. What if both the devs want access to each others code (can they add other forks as remote repositories and then play with each others code and later try to push up into the main repo? I think it might generate conflicts and is a bad practice.. is it?)
        Main repo
           /     \
   sub1 <--> sub2
   If sub1 adds sub2 as remote repo and pulls in changes and later tries to create pull request for Main repo, there would be conflicts and other issues, right?
4. Any other way to manage code in situations like these?

Bonus: How to restrict access to full code base for some freelancer/other devs who might be working temporarily ? (more from a management perspective rather than code)

Answer 1

1. The relationship described in your diagram is completely fine and correct approach.

2. In question 2 though you're missing a point of distributed nature of git. I'll try to describe the simplest example: each developer should have a clone of the repo with master branch. When they develop the preferred approach is to develop in so called feature or topic branches. I.e. branch that is dedicated to a particular feature or bugfix or whatever. This allows for parallel development of different features. but those branches don't need to be shared on the mainline, they can and should remain local (although it doesn't hurt to push them to mainline if needed) Now if they want to exchange their code without affecting your mainline they can add each other repos as remotes and track each others branches as needed. Then when it's time to actually merge their effort and push it to master one of them should take care of it as an integrator (or you) The branching is very lightweight in git, you will start using branches more often and you will not be able to understand how did you work without branches before in no time.

Another approach is to have an integration branch on mainline. That might be master, or separate branch maintained for that single purpose. When some piece is ready on dev side, developer switches his local repo to the integration branch, pulls latest changes and merges/rebases his topic branch in and then pushes it back to mainline

1. in the scheme described above developers will have access to only the code that is committed. But of course if they are working on the same piece of code conflicts are possible. And they will have to resolve them, which is normal workflow in any VCS. The only advice here is to make sure that you're not overwhelmed by the size of conflicts, therefore you should use basic strategies like:

a) commit more often b) Commit smaller chunks that are single functional unit, don't commit hundred of files. c) integrate more often

BONUS: you can't restrict access to a part of the repo, so use component oriented approach and split things into different repos. That will not only allow for granular access management, but also will reduce the amount of integrations (as not the whole codebase is affected but every commit), plus as a bonus it might enforce better design.