使用GIT拆分多方面C#项目

我们最近将回购管理从SVN切换到GIT，并且很好地掌握了非线性源代码控制风格。目前，整个代码库（服务、Windows/Xamarin客户端和ASP.net网站的混合）都被转储到了repo中，包括各种核心库

为了进一步改进我们的工作流程，我尝试将我们的所有项目分离到它们自己的存储库中（例如：一个用于Web服务，一个用于Windows程序，等等），达到大约总共6个左右共享一些代码的独立项目

现在，我已经对一些不同的解决方案做了一些研究，但我正在努力找到一个折衷方案。最后，我们希望锁定核心库的

master

分支，因为它们是任务关键型的，需要通过pull请求进行同行审查。只有到那时，他们才会被接受

我的第一个想法是使用GIT子模块，但经过一些研究后，我发现人们更倾向于使用较新的子树概念

我在停机时间玩过子树，看不到任何方法可以为父项目的不同分支选择远程子树的不同分支（例如核心库）

我也尝试过NuGet包，但这里没有满足可编辑源代码的要求，该源代码可以提交并批准

---

我还没有认真研究过这里的子模块，所以这里可能需要它们固有的复杂性？还是我遗漏了什么？

我不知道你的问题是什么，但是关于：

。。。无法为父项目的不同分支选择远程子树的不同分支（例如核心库）

您是否建议将父项目的分支链接到子树上的分支？如果所有的子项目都倾向于与超级项目同步提交，我认为有一些类似于git slave的东西更适合这样做

如果您倾向于主要处理超级项目，并且偶尔会对子项目进行更改（您可以决定何时将更改推回到子项目跟踪存储库），则子树更为理想

把它想象成一种中间件

您可以从供应商处获得帮助，并确保您的代码与所做的任何api更改一起工作。从那时起，它只是超级项目存储库的一部分。快乐地做出改变。如果您做了一些很棒的事情，并希望将其贡献回子项目，请将其拆分为一个分支，然后将其合并到子项目的一个分支中，并从那里发出请求

在开发过程中，您还可以定期从“供应商”中提取更改以更新子项目

因此，我不确定这是您想象的工作流，但您确实可以通过分支将子树更改推送到子项目

关于拆分语法和示例，我将参考。 参见：“示例3.使用分支提取子树”

---

以下是我对您工作流程的设想：

多个超级项目使用子树将子项目拉入文件夹。当子项目发生变化时，它们不会自动神奇地获得变化，这很好，因为您希望控制拉动的时间，以便确保一切正常

标准的工作流程是克隆主项目，在分支上工作，并将更改提交回超级项目（实际上可能包括对子项目的更改，但超级项目仍然可以像正常情况一样通过合并请求工作流程进行控制）

也许对子项目所做的一些更改并不完整，或者它们只是适合超级项目的当前状态，但还没有准备好广泛分发给其他超级项目。

---

在这种情况下，您可以在更改准备就绪之前不将其拆分（至少您在超级项目中对其进行了跟踪），也可以将更改拆分为分支。创建主子项目的一个分支，并推送到该分支。如果您对这个子项目有严格的合并要求，那么您就可以提出请求，但不要将其与现在必须从子项目的那个分支拉到您的工作超级项目相混淆。您希望这样做的唯一原因是，如果您有两个超级项目，在您正式将子项目工作提交给主项目之前想要共享子项目工作。

如果您需要将子项目提交给超级项目：

您可以使用触发器脚本来禁止用户向master提交任何有子项目更改的内容，并在需要时强制他们首先进行分支。然后处理对超级项目主控器的请求，并将子项目更改自动拆分到子项目跟踪存储库

我认为需要有一种方法让用户同时对超级项目和子项目进行更改，以跟上界面的变化

在另一个方向上，当您从子项目中提取时，您必须同时更新超级项目，因此这应该涵盖这两种情况

---

注意，您必须从特权用户（处理合并请求的用户）中执行子树拉取，或者，用户将不得不向分支机构执行建议的拉入操作，并提交拉入请求，因为它将包含子项目更改，从而触发签入脚本。

您提到了在准备就绪时推回子回购的上游的想法。在我的sceario中，当对核心库进行更改时，需要进行代码审查/拉取请求，主要是为了确保任务关键型的东西不会被轻易地玩弄，同时也可以通知其他开发人员对核心库的任何更改，如方法签名更改和添加的功能。我不认为有问题。使用子树，您基本上拥有子项目的多个副本，并且可以手动执行