我想知道你通常如何应对这种情况：
我有一组实用功能。说..5..10文件。从技术上讲，它们是静态库，跨平台 - SConscript / SConstruct和Visual Studio项目（不是解决方案）。
这些实用程序功能用于多个小项目（15+，数量随时间增加）。每个项目都有一些文件或整个库的副本，而不是指向一个中心位置的链接。有时项目使用一个文件，两个文件，有些使用一切。通常，实用程序函数包含在每个文件和SConscript / SConstruct或Visual Studio Project的副本中（具体取决于具体情况）。每个项目都有一个单独的git存储库。有时一个项目来自其他项目，有时则不是。 你以随机顺序处理它们中的每一个。没有其他人（为了简化事情）
在处理一个项目时，您会修改这些实用程序功能文件时出现问题 因为每个项目都有一个文件的副本，所以这会引入新版本，当你稍后（例如一周后）尝试猜测哪个版本具有最完整的功能时（即你在a.cpp中添加了一个函数）会导致混乱。一个项目，并在另一个项目的a.cpp中添加了另一个函数，它创建了一个版本fork）
你如何处理这种情况以避免“版本地狱”？ 我能想到的一种方法是使用符号链接/硬链接，但它并不完美 - 如果你删除一个中央存储，它将全部下地狱。并且硬链接不适用于双启动系统（尽管符号链接会）。 看起来我需要的是像高级git存储库，其中项目的代码存储在一个本地存储库中，但与多个外部存储库同步。但我不知道该怎么做，或者是否可以用git做到这一点。
那么，您怎么看？
答案 0 :(得分：2)
通常的简单方法是将库作为版本控制中的项目，如果有修改，则只编辑该项目。
然后，需要该库的其他项目可以从库项目中获取所需的文件。
答案 1 :(得分：1)
我不清楚你想要什么，但也许git子模块可能会有所帮助：http://git-scm.com/docs/git-submodule
答案 2 :(得分：0)
在Subversion中你可以使用外部（我知道它不是GIT，但这些提示可能仍然有用）。这是它的工作原理：
您也可能拥有应用程序的版本。还介绍了通用代码中的版本。因此，您的应用程序将在存储库中包含以下文件夹：
同样，使用版本号添加版本到公共代码，如下所示：
或使用日期，如下：
\ MYAPP \ TRUNK的外部应指向\ COMMON \ TRUNK，这是显而易见的。
尝试将公共代码的版本与应用程序的版本同步，因此每次修复应用程序版本时，公共代码也会被修复，应用程序版本将指向外部的相关公共代码
E.g。 \ MYAPP \ V1的外部可能指向\ COMMON \ 2010JAN01。
这种方法的优点是每个开发人员现在都可以扩展，改进和调试公共代码。缺点是应用程序的编译时间会随着通用代码的增加而增加。
替代方案（在您的版本系统中放置库）的缺点是公共代码的管理（扩展，改进，调试）总是与应用程序的管理分开完成，这可能会阻止开发人员编写通用的公共代码完全（并且每个人都开始编写他们自己的'泛型'类的版本）。 另一方面，如果您有一个明确而灵活的团队，对公共代码负全部责任，那么在最后一个替代方案中，公共代码将受到更好的控制。
答案 3 :(得分：0)
在配置（一般）术语中，解决方案是拥有多个中继（分支）：
<强>版本
此主干/分支包含已通过质量保证并可以发布给客户的软件。发布后，所有文件都标记为“只读”。给出标签以标识具有版本号的文件。
定期或按需要求测试大师将从集成主干中获取最新（提示）版本并提交到严格的质量测试。这是集成版本升级到发布版本的方式。
<强>集成
该中继包含最新的工作代码。它包含错误修复和新功能。每个错误修复或新功能后都应标记文件。
在错误通过质量测试或新功能完全开发（并经过测试）后，代码将移至集成分支。这里的一个好主意是在集成开发人员代码之前用集成版本标记临时标签。
<强>开发 这些是开发人员为修复错误或开发新功能而制作的分支。这可以是移动到本地计算机上的所有文件的副本，也可以是需要修改的文件的副本（包含所有其他文件的Integration干线的链接）。
在中继线之间移动时，代码必须通过资格测试，并且必须有权移动到中继线。例如，未经授权，不应将未经授权的新功能放入集成分支。
在您的情况下，文件需要在修改后重新检入Integration trunk，或者如果代码与以前的版本太不相同（例如添加新功能），则需要检查整个新的分支或主干。
我一直在研究GIT和SourceSafe试图弄清楚如何实现这个架构。该模式易于在较大的配置管理应用程序（如PVCS和ClearCase）中实现。对于GIT来说，重复的存储库是必要的（每个主干一个存储库）。 SourceSafe明确指出每个版本只允许一个标签，因此未更改的文件将丢失标签信息。