Splitting multi-facet C# project using GIT

Question

We recently made the switch from SVN to GIT for our repo management, and have a good grasp on the non-linear source control style. At the moment, the entire codebase (Mixture of Services, Windows/Xamarin clients and ASP.net website) was dumped into the repo, including various core libraries.

To further improve our workflow, I am trying to separate out all our projects into their own repositories (eg: one for Web Servies, one for Windows Program, etc...), reaching an approximate total of 6 or so separate projects sharing some code.

Now, I have done some research on a few different solutions, but am struggling to find a compromise. In the end, We wish to lock our master branch of our core libraries, as they are mission-critical and require peer review through pull-requests. Only then will they be accepted.

My first thought was to use GIT submodules, but after some research, I discovered that favour had been given to the newer concept of subtrees.

I played with subtree's in some downtime, and couldn't see any way to choose different branches of a remote subtree (such as the Core Libraries) for different branches of the parent project.

I gave NuGet packages a go as well, but the requirement of editable source which could be committed back and approved was not fulfilled here.

I still haven't seriously looked at submodules here, so maybe their inherently complicated nature is required here? Or am I missing something?

Answer 1

I can't exactly tell what your question is, but regarding:

... couldn't see any way to choose different branches of a remote subtree (such as the Core Libraries) for different branches of the parent project.

Are you suggesting that you want to link a branch of the parent project to branches on the subtrees? If all of the sub-projects tend to be submitted in sync with the super-project, I think there's something like git slave that's a better fit for that.

Subtrees are more ideal if you tend to work on the super project primarily and occasionally contribute changes to the sub-project which you can decide when to push back to the sub-projects tracking repository.

Think of it kind of like middleware.

You get a drop from the vendor, and make sure your code works with any of the api changes made. From that point on it's all just part of your super-project repository. Make changes happily. If you do something awesome and want to contribute this back to the sub-project, split it out into a branch, and then merge it into a branch of the sub-project and make a pull request from there.

Periodically as you're developing you can also pull down changes from the "vendor" to update your sub-projects.

So, I'm not sure this is how you imagined the workflow, but you can indeed push subtree changes to the subproject via a branch.

I'd refer to https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt for the split syntax, and example. See: "EXAMPLE 3. Extract a subtree using branch"

---

Here's how I'm imagining your workflow:

Multiple super-projects pull in the sub-projects into folders using subtree. They don't auto-magically get changes as the sub-projects change, which is good because you want to control when you pull so that you can ensure everything still works.

Standard workflow would be you clone master, work on a branch, and commit changes back to the super-project (which may in fact include changes to the sub-projects, but the super-project can still be gated by merge request workflow like normal).

Perhaps some of the changes that have been made to the sub projects are not complete or they just fit with the current state of the super-project, but aren't ready for wide-spread distribution to the other super-projects. In this case you can either simply not split the changes out until their ready (at least you have tracking of it in your super-project), OR you can split the changes out to a branch. Create a branch of the main sub-project and push to that. If you have tight merge requirements for this sub-project that's how you'd propose pull requests, but don't confuse that with having to now pull from that branch of the sub-project to your working super-project. The only reason you'd ever want to do that is if you have 2 super-projects that want to share the sub-project work before you have officially committed them to the master.

Answer 2

If you need to gate your sub-projects on the super-project:

You could use a trigger script to disallow users from committing anything to master that has a sub-project change, and force them to branch first if they need to do that. Then handle pull requests to the super-project master and split the sub-project changes to the sub-project tracking repository automatically.

I think there needs to be a way for users to make changes to both the super-project and sub-project at the same time, in order to keep up with interface changes.

In the other direction, when you pull from the sub-project, you have to update the super project at the same time, so that should cover both cases.

Note, you'll either have to do the sub-tree pull from a privileged user (one that handles merge requests), or the user will have to do the proposed pull to a branch and submit the pull request since it would contain sub-project changes which would trigger the check-in script.