共享库的分支和版本控制策略
这些 帖子似乎相关，但是我的大脑开始融化，试图通过：P来思考 我的雇主刚刚开始使用源代码控制，主要是因为在雇用更多开发人员之前，“存储库”是唯一的开发人员的硬盘驱动器，该开发人员主要在家中工作。所有他写的.NET代码的检入集体，并有大量的重复（读：复制粘贴）功能。现在，我们的SCM系统是光荣的备份。 我想将某些重复的代码放入共享库中。我将单独保留原始存储库，以便我们不会破坏任何内容，我们可以在需要时移动和/或重构现有代码。因此，我为新代码（包括库）设置了一个仓库。 我的问题围绕着对库进行版本控制而没有过多的时间来烦恼我们：承认我们需要一种更一致的方法，更多的开发人员都编写非常相似的代码，管理人员和其他开发人员都愿意进行重组，但可能不会如果解决方案开始影响生产效率，则下降得很好。 在我的痴迷心中，理想的解决方案是分别构建库，而每个从属项目都是针对故意选择的兼容版本构建的。这样，我们就可以准确地知道哪些客户端具有哪个库的哪个版本，可以更可靠地重现错误，维护产品和库的独立发行分支，并且在更改共享代码时不会破坏彼此的项目。 但是，这使得更新库很麻烦，尤其是对于在家工作的开发人员而言。我希望这些库能快速变化，至少在最初（最终）将这些通用位组合在一起时会如此。我完全有可能对此进行全面考虑，并且可以根据最新的库提交构建所有内容，但我至少要做好准备，以便我们决定某些组件必须独立版本化并分散式。必须在GAC中安装某些库这一事实使得版本控制特别重要。 所以我的问题是：我想念什么？我觉得我已经专注于一种解决方案，现在正在尝试寻找可以使更改更平滑的变体。您以前使用过哪些策略来解决此类问题？我意识到这个问题无处不在。我会尽力清理并澄清所有不确定性点。 尽管我很想使用Mercurial，但我们已经在集中式商用SCM（Vault）上花了钱，并且切换不是一种选择。此外，我认为这里的问题比版本控制工具的选择更深。