我们可以使用SVN还是Git？对于以下用例
我们如何组织系统：
1："主仓库"包含所有项目和独立驱动程序，因为项目使用的每个项目/驱动程序都是不同的"分支"？
示例：
MasterRepo
|-Project1
| ---Hardware
| --ECAD
| ---Firmware
| --src
| --includes
| ---Documentation
|-Project2
| ---Hardware
| --ECAD
| ---Firmware
| --src
| --includes
| ---Documentation
|-Drivers
| ---driver1
| --src
| --includes
| ---driver2
| --src
| --includes
2：每个项目和独立驾驶员的单独存储库？我们将需要从驾驶员存储库中"拉"或"合并"到项目存储库中。在驱动程序层中发生错误的情况下，显示出障碍的障碍，这一点很重要。
Project1Repo
|---Hardware
| --ECAD
|---Firmware
| --src
| --includes
|---Documentation
Project2Repo
|---Hardware
| --ECAD
|---Firmware
| --src
| --includes
|---Documentation
DriversRepo
|---driver1
| --src
| --includes
|---driver2
| --src
| --includes
硬件应该完全放在单独的存储库中吗？
每个驾驶员都可以单独存储吗？
我们是汽车行业中的嵌入式电子公司。在我启动软件团队之前，没有使用任何版本控制系统，所有内容均通过文件夹和Zips"版本化"。事物的硬件方面仍然使用这种版本操作。
我们已经开始使用SVN(但不绑在上面(。目前，我们使用以下内容的Adhoc构成模型：
MasterSoftwareRepo
|-Documentation
|-MicroControllerMFG1
| --FamilyOfMCUs
| --Drivers
| --Projects
| --Project1
| --active
| --src
| --test
| --build
| --release
| --srev1
| --srev2
| --srev3
| --projectSupport
| --Project2
| --active
| --release
| --projectSupport
| --Project3
|-MicroControllerMFG2
| --FamilyOfMCUs
| --Drivers
| --Projects
| --Project10
| --Project11
| --Project13
|-MicroControllerMFG3
| --FamilyOfMCUs
.......................and so on.
系统的工作原理...它不漂亮，也不有效。因为我们只使用了6个月的系统，并且总存储库的大小超过40Gig。由于结构，我们实际上使用了预期的版本控件，其具有历史记录的文件夹。
也有更多背景，我们的团队是中型的，但是从事每个项目的团队很小... 1个软件，1个硬件，每个项目1机械。我们每个人都可能一次有1-2个项目。我们部门有20个人。
因此，由于在同一项目或文件上工作的人而导致的合并冲突的重大想法是不存在的，因为存储库确实在这里跟踪自己，并保留更改的文档等。
对我们的用例有什么建议？我们相信的1个回购想法太大了，但是我们坚持使用它的想法，以便我们可以从驾驶员那里拉出。和基本项目结构等。因此，我们可以完全易于访问。
硬件应该是单独的回购吗？我们可以将其包括在我们的存储库中，还是我们该怎么做？
不使用托管解决方案，所有解决方案都必须自托管。
是的，我知道这是一篇很长的帖子，但是我认为我给出的细节越多，您就可以更好地理解情况和我们的用户酶。
如果您已经使用了存储库已有6个月了，并且已经大小为40个演出，那么它可能会变得太大，无法随着时间的推移轻松管理。
对于像您遇到的问题一样，我建议您切换到git-但使用git-lfs来管理二进制(非ASCII(文件。git -lfs允许用户在本地使用最新版本的二进制文件 - 而对于正常的git，每个文件的所有先前版本都在本地存储(以压缩形式(。
这将使您可以将文档和ECAD保留在同一存储库中 - 但仅查看本地文件的当前/最新版本。
我认为第一个存储库选项将是当前最好的解决方案
MasterRepo
|-Project1
| ---Hardware
| --ECAD
| ---Firmware
| --src
| --includes
| ---Documentation
|-Project2
| ---Hardware
| --ECAD
| ---Firmware
| --src
| --includes
| ---Documentation
|-Drivers
| ---driver1
| --src
| --includes
| ---driver2
| --src
| --includes
至于分支机构的数量 - 您是否可以通过拉动请求在分支上进行所有测试？还是您需要更改以进行1-2个月的测试，然后才能确定它们是否稳定/良好？
如果第一个选项是现实的，我认为单个"主"分支将起作用 - 在将PR合并到主主线之前，您提交拉动请求并在该分支上进行所有测试。
如果第二个选项更好，则可以使用双分支结构 - 一个"主"和一个"稳定" - 您拥有正在测试的主要开发分支 - 以及最终版本/稳定分支，其中更改将走 - 一旦在开发线上证明了它们。
如果将来您打算拥有大量的项目，即使存储每个文件的单个副本也变得太大，您也可以研究git subsodules(单独的存储库，但每个项目存储库都包含一个指向特定的指针在另一个存储库中的时间点(。最后一个选项是考虑使用虚拟文件系统进行git-但是此选项将限制您可能正在研究的任何GIT GUI选项。