我知道有很多发行版本控制方案（例如，语义），但是我找不到有关源代码版本控制的任何指南。是否必须通过VCS（如Git）进行跟踪，或者可以独立进行版本控制？例如，我要跟踪md5.c模块的其他版本，而与使用该文件的项目无关。
答案 0 :(得分：0)
首先：是的，您确实希望代码从一开始就受到版本控制。无论项目的规模如何，切勿接受除完整的版本控制系统之外的任何功能，最好是git，尤其是Dropbox或乱扔文件夹进行源代码管理之类的东西。
分支方案： 发行版本控制主要是更有益的代码版本控制方法的结果。通常，您会希望在公司中实施一个版本控制方案（=分支方案），并使人们坚持下去。从不断增长的代码库中可以看到发行了新版本并获得了版本标签，但是所有非发行版仍然可以在任何时间使用每个人的相同系统进行版本控制。这是使协作和维护透明化和起作用的唯一方法。
对于更复杂的项目，流行的分支方案是git flow方案。请找到文档here。基本思想是拥有一个持续的开发分支，您可以在其中合并新功能（每个功能在单独的分支上进行开发），然后将发布合并到稳定的分支中。基本上，分支用于按其稳定性对代码进行排序，从无法单独依靠的独立功能分支开始，再到永远值得信赖的稳定发行分支。
还有其他分支方案，具体取决于贵公司的需求，例如官方git docu here或Atlassian here的Bitbucket docu中。环顾四周，并根据您的企业需求做出决定。 Git流是一个很好的起点，但也许您想要更浅的东西。
相互依赖的项目： 软件工程中的经典之作。假设您有一个在版本控制下开发的软件包。现在，此软件包将由其他几个人独立使用-您是否会将它复制到每个相应的存储库中，从而实质上失去对它的版本控制？
这就是submodules的用途。 Git允许您将存储库加载到存储库中，基本上是嵌套版本控制。现在，您将按照自己的喜好在版本计划下开发共享软件包，然后将其简单地导入其他项目（现在称为子模块）中。当您实现现在要在从属中看到的新功能时，您可以启动更新，然后只需将新版本从原始存储库中提取到使用它的存储库中（有点类似生产者/消费者），这样就可以始终保持上游的开发历史记录对每个项目中存在哪个版本的依赖项保持透明。