我有一个具有以下层次结构的项目：
Tharwa
|_tharwa-backend
|_tharwa-web
|_tharwa-mobile
每个子文件夹都是自己的存储库;我想创建将所有内容放在一起的存储库Tharwa。
但我有以下限制条件：
我不想将它们放在与子文件夹相同的repo中，因为每个子文件都有自己的依赖项和配置文件，而且我也不希望它们的提交混淆。
我不想将它们留作单独的回购，因为我在父回购上有问题，可能需要在后端和移动回购上完成工作，我希望有问题在同一个分支上解决，例如：
__________________________ master
\________________________ develop
\______/ login
我的问题是，我怎样才能做出这样的事情呢？我哪里弄错了？
如果我没有好好解释，请告诉我。 提前谢谢
答案 0 :(得分：3)
基本上有3种方法可以看到它：
我不知道你的约束“我不想让他们的提交混淆”。来自，也许只是因为你还不太了解git。现在请注意，你在git中有powerfool工具和选项来查看提交，按日期，作者，路径，内容等过滤。所以在我看来，这没什么可担心的。相反，这允许您通过唯一提交清楚地显示第一个项目中的文件X与第二个项目中的文件Y同时更改（例如，因为您更改了API，因此您需要更改时间API的生产者和消费者，这应该只反映在一个提交中。）
但是如果你想要严格的提交隔离，你可以在选项3和选项2中使用它。不在选项1：那里，一个提交可以涵盖任何子项目的更改。
关于你的第二个约束，它可以在选项1中立即实现，在2中可能，但肯定不在3中。
git子模块本身值得讨论，因为它们有自己的约束。在大规模使用之前，请务必阅读并了解它们。 除了官方文档（第一个链接）
之外，还有一些有趣的链接关于子模块和分支的具体问题，请看一下这个问题及其答案：Git submodules: Specify a branch/tag
就像我在评论中写的那样，事情也取决于你如何打包和分发这个软件。它总是按原样部署一段代码（选项1和2会更有意义），或者你只能将一个项目与其他项目分开发布（选项3会更有意义）。 请注意，我说“更有意义”，因为它不是黑白的，你可以随时在任何选项中实现你的目标，妥协只是不同。
这还取决于将在这些方面开展工作的开发人员队伍。他们对git的知识水平是多少？子模块不是我推荐给git初学者的东西。以及如何在远程存储库之间推送/拉出提交？在选项1中，您有一个存储库可以满足，在选项2中也需要更新子模块（请参阅文档），在选项3中，您有3个单独的存储库来处理。
可能还有其他要点可以考虑到帐户，但如果您从空内容开始，它们可能无关紧要。像大小一样。有些存储库有时可能包含大量历史记录，这会影响git clone（例如，如果一个存储库很大，则会产生单独的存储库，这不会影响其他存储库）。
您似乎暗示了http://nvie.com/posts/a-successful-git-branching-model/所述的工作流程，这是一个良好的开端。如果你想坚持下去，那么在选项1中很容易，但很可能但在2中并不精确，而在3中则不可能。 （并查看https://www.atlassian.com/git/tutorials/comparing-workflows以了解其他一些可能的工作流程）
在我看来，你的两个限制是相反的方向，所以你需要看看哪一个比另一个更重要。
至于我自己，但如果没有你的整体情况，我会赞成选项1，因为它似乎是最灵活的选项（从中你可以轻松切换到选项2或3之后）。
答案 1 :(得分：0)
我不想将它们放在与子文件夹相同的repo中，因为每个子文件都有自己的依赖项和配置文件，而且我也不想让它们的提交混淆。
好的，你不希望他们的提交混淆。
我不想将它们留作单独的回购，因为我在父回购上有问题，可能需要在后端和移动回购等方面完成工作，我希望问题在同一个分支上解决了......
...除非您希望他们的提交混淆。 ;）
我哪里错了？
如果您必须习惯性地同时更改多个存储库，您可能需要考虑它们是否实际上是单个存储库。有两种处理这种方法的好方法，子存储库不是其中之一。
一个是使它们成为单个存储库。如果他们是同一个项目的所有部分，并且他们有相互依赖的变更，那么他们就是一个单独的存储库。他们可以成为具有自己的配置和依赖关系的子文件夹，这对于需要一起开发但需要分发以进行分发的大型项目来说是相当常见的。
缺点是开发人员可能会利用这一点并将客户端代码紧密绑定到后端。如果项目之间没有明确的分离，后端API可能会变得草率。客户更有可能利用未记录的后端功能，使整个系统变得脆弱，并且能够抵御变化。添加新客户端（例如，tharwa-api可能会变得更加困难。
如果你有第三方为tharwa-backend写自己的客户，他们就处于劣势。 client和web处于特权状态，可以与backend保持同步。第三方开发者并不是那么幸运，你的项目将更难为之做出贡献。
一旦你把你的项目放在一起，你就不可能再将它们分开了。
另一种是通过每个repo将对方视为正常依赖关系来更严格地强制执行对封装之间的封装。在login示例中......
backend上实施，测试和提交更改。backend，即使仅用于内部发布。web测试mobile和backend，以确保维持向后兼容性。web和mobile更新其backend依赖关系并使用新功能。现在开发人员更难欺骗。释放的额外步骤（不应该超过一分钟或两分钟）提供了空气间隙＆＃34;。 backend必须开发自己的单元，集成和验收测试;它不能依赖客户为他们做这件事。客户端必须更加强大，并且更严格地遵守后端API。随着后端和客户端分离，对每个 internals 进行根本性更改会更容易。
开发人员仍然可以进行锁步更改，但现在他们已经明确了。使它们明确地阻止它们的使用，它可以防止开发者变得懒惰。
但它确实增加了一些开销。 backend更改必须经过充分考虑，开发和记录。 backend API必须更加完善和强大。客户必须更加贴近API。所有这些都是良好的软件工程，并将在中期和长期加快速度。
子模块提供了单个仓库的大部分优势，但增加了一个令人困惑的功能。它还提供所有单个回购的缺点，再加上一个：缺乏协调。
使用单个repo，一次提交就是一次提交。一个分支是一个分支。对于子模块，通过查看单个存储库很难知道哪些提交必须在所有存储库之间进行协调。这些协调的提交可以在任何时候发生，没有任何警告，而且很难知道。
您需要一些程序和机制来跟踪和协调这些提交。你可以通过试验和错误自己构建这个，也许是带有标签或特殊提交消息的东西。
或者您可以使用现有的版本依赖系统。
您选择哪个取决于您的项目。不过，我建议您尝试完全解耦，看看它是怎么回事。它鼓励良好的软件工程实践。你可以随时把它们重新组合在一起，很难相反。