How to organize work between 2 git repos?

Question

We have a setup where we internally use git to do our work and at the same time the client we deliver the work to also uses git on their own.

We also want to have a strict border between 2 repos so that client is not involved into our repo workflow (internal issues, users, PR policies, etc) nor we want to be involved into their.

We are considering workfow like this:

1. Our devs do all their work against our-repo in development branch (set as default)
2. Our repo admin has access to client-repo (meaning he has 2 remotes: our-repo and clients-repo)
3. Once something is ready to deploy (meaning, is pushed to our master branch) he gets it and push it to clients-repo
4. In case client themselves do some changes (rare but possible), our admin gets it and merge to our-repo

Would this setup work? Am i missing anything important? Are there any better alternatives?

Answer 1

I see github.com's permission matrix at https://help.github.com/articles/repository-permission-levels-for-an-organization/

Your wish can not be reality, if our team and our client use github.com in same time (let see matrix at row Open issues, pull, etc.)

I have an idea

• Our team use github.com service

• Our client use a git mirror repository (not on github.com) https://help.github.com/articles/duplicating-a-repository/

Therefore, our client cannot see pull request process, issue, issue discussion, etc. they only see source code what our team deliver to them.

Answer 2

I think that having two separate repos which both contain logically the same (or at least very similar) code is unnecessary, and a generally bad idea. I suggest that you just maintain a single repo. Make the master branch (and possibly other branches) protected in GitHub. You may read Enabling branch restrictions for more information on how to do that.

When your clients want to do their own work, simply let them create a new feature branch. If they want, they may create a pull request back to master, which you and your internal team can carefully review, before merging. Since master would not be protected, your client would never have the direct ability to alter the codebase.