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