title: Storing submodules for micro services, but still using forks
body: <p>I am stumped here.  A lot of this is already in place, its just the wrapping that I cannot figure out.</p>
  
  <p>We have a micro-service architecture, with many separate repositories.  We are using Docker, and Docker Compose for building and running the development environment, which works beautifully.</p>
  
  <p>The question I have, is how to package up the main collection of repositories.  So if I have a folder structure like:</p>
  
  <pre><code>\
      service1
          .git
          Dockerfile
      service2 
          .git
          Dockerfile
      service3
          .git
          Dockerfile
      docker-compose.yml
      README.md
  </code></pre>
  
  <p>...Where service1, service2, service3 are each their own git repository.</p>
  
  <p>My first thought was to use git submodules, which <em>would</em> work, however we enforce policies to require developers to fork repositories instead of working off the main repository due to continuous integration constraints and code reviews.  I was not overly excited about using git submodules at all, even before I thought of this caveat, so an alternative solution would be much preferred.</p>
  
  <p>At the moment i can only think to write scripts to store a list of repositories; run a query for each to see if the logged-in developer has a fork of each, creating one if not, then pulling into the master folder; and then booting docker-compose.  This seems like a horrible solution though, enough so that I may just have to write docs to just tell devs how to manually do this process...</p>
  
  <p>Thoughts??</p>
  
  <p>Thanks for your time :)</p>