2

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?

2
  • 2
    make common a library and share the versioned binary rather than the code
    – Ewan
    Apr 21, 2017 at 7:36
  • I suspect that's the path I will have to go down in the long run. Apr 24, 2017 at 6:48

1 Answer 1

1

I suggest using submodules instead of subtrees as common is a component of both server and client. With submodules, each branch of the parent (in your case client/server) repository can point to a commit of the child repository (in your case common).

For more details please refer to Git Submodule documentation

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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