We have one project and separate teams which work on separate modules. What we need is a strategy that allows our teams to work on one project but without access to each other source codes.

  1. one project
  2. multiple teams (separate)
  3. each team doesn't have access to other's source code
  4. ability to merge repositories (or any separate commits from each teams) (optional)
  5. teams do not work on same file
  • 1
    Sharing your research helps everyone. Tell us what you've tried and why it didn't meet your needs. This demonstrates that you've taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Nov 4 '19 at 8:20
  • What you are asking is impossible. Merging is performed on a per-file basis, and it is not possible for two teams to work in the same file without seeing each other's code. – Bart van Ingen Schenau Nov 4 '19 at 8:27
  • @BartvanIngenSchenau nor same files but same project. each teams works on separate module and separate files – Hamid Nov 4 '19 at 9:42
  • @gnat I have generate two repositories in one project and assigned team's developers to each repos so far. Although I can check those repos by fake users till find out how separate repos works and what abilities git gave me with two repos in one project but I though users may answer me fast and having better solution for my requirements. and in addition this solution helps others later with one search (what I have done before posting this question) – Hamid Nov 4 '19 at 9:48
  • This is not a source control problem, but a team structure and software architecture problem. If you want different teams working independently, you need to make sure that the things that they work on are truly independent (separately versioned, independently releasable). Not try and patch over it with VCS wizardry. See also: Conway's Law. – Ant P Nov 11 '19 at 12:05

The way I would setup my repositories in an environment like this is

  • Each module gets their own git repository for the source code.
  • There is a central artifact repository that stores the binary artifacts of all the modules
  • The build system for each module retrieves the dependencies from the central artifact repository.
  • There is an automated build server that builds each module periodically (weekly, nightly, after every merge to develop/master, etc.) and uploads the build to the artifact repository.

For the artifact repository, I would recommend against git, because there are far better solutions available. Which one to use depends partially on your technology stack, because some stacks work better with some repositories than others.

This setup assumes that each module can be built into a library/executable without having a circular dependency with another module.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.