I am working on a team that is geographically distributed between Australia and the Philippines. Until recently, we have been using a single SVN server to maintain our code, with the server containing a few repositories (let's call them Client, API and Common), with Common code shared between Client and API via SVN externals. We use TeamCity for CI, and Octopus Deploy for automated deployments; feature releases are typically done every 2-3 months, with maintenance releases as and when needed.
We are now moving to BitBucket as our VCS, and are having a few issues with the overall workflow. Firstly, for external audit issues, we need to prevent all developers from being able to commit to the master repositories, so we forked client-development, api-development, and common-development repositories, and granted only team leaders write permissions on the master repositories, and everyone write permissions on the -development repositories. So far, so good.
The main problem we are having is with the sharing of code in the Common repository. When a developer starts work on a new feature, they need to create branches on each of the three repositories, and then create a subtree on client-development and api-development that links back to common-development, using the newly-created branches. But then when they push their code back, and someone else then tries to use that code, the subtree has disappeared, and is now just a regular folder in the source code.
I think our overall best workflow strategy would be a variation of gitflow, where -master is the "pristine" copy which only team leads can modify by accepting pull requests, and all the other features of gitflow are implemented on the -development forks. However, the problems of subtrees is really slowing us down.
How can subtrees effectively be used to share code between repositories, without having to delete and recreate them every time you merge code?
