我们应该使用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
硬件是否应完全放在单独的仓库中？（我们是嵌入式软件工程师，我们需要查看原理图并知道何时有更改或建议更改等。）
每个驱动程序都应该放在单独的存储库中吗？
我们是汽车行业的嵌入式电子公司。在我开始工作之前，软件团队没有使用任何版本控制系统，所有内容都通过文件夹和zip“版本化”。并且硬件方面仍然使用这种版本控制方式。
我们已经开始使用SVN（但不限于此）。目前，我们正在使用使用以下临时性模型的软件：
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回购协议的想法太大了，但我们仍然坚持使用该想法，因此可以从驱动程序中撤出。和基础项目结构等，因此我们从一开始就具有完全的可处理性。
硬件应作为单独的存储库吗？我们可以将其作为分支包含在我们的回购中吗？
不使用托管解决方案，所有解决方案都需要自托管。
是的，我知道这是一篇很长的文章，但是我认为我提供的详细信息越多，您就可以更好地了解情况和我们的用例。
答案 0 :(得分：-1)
如果您使用该存储库已有6个月，并且已经是40 gigs，那么它可能会变得太大而无法随时间轻松地进行管理。
对于您遇到的问题，我建议切换到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个月的测试才能确定其是否稳定/良好？
如果第一个选项是现实的，我认为可以使用一个“ master”分支-在该PR合并到主master行之前，您可以提交拉取请求并对该分支进行所有测试。
如果第二种方法更好，则可以采用双重分支结构-一个“主”和一个“稳定”-在这里，您有一个正在测试的主要开发分支-在最终版本/稳定分支中，进行了更改一旦在开发线上得到验证，便会成功。
如果将来您打算拥有大量项目，即使每个文件的单个副本都存储得太大，那么您也可以查看git子模块（单独的存储库，但是每个项目存储库都将包含指向特定对象的指针时间点在另一个存储库中）。最后一个选择是使用Virtual File System for git-但此选项将限制您可能正在研究的git GUI选项。