我们目前正在为我们的项目使用StarTeam，许可证即将到期。我们正在考虑迁移到Team Foundation Server或类似的东西，但是有一种推动（主要是来自我自己和另一个人）转向某种形式的分布式版本控制。其中一个问题是我们的变更经理希望能够通过变更请求进行跟踪和发布（如在StarTeam中），我不相信这可以通过Mercurial或Git开箱即用（请如果我错了，请纠正我。）
这是一个拥有15年历史的产品，拥有数千个java文件和PL / SQL包，由5-6个开发子团队维护，共有30-40个开发人员。对我而言，这似乎会使分布式存储库成为“早期提交，经常提交”思维模式的噩梦。事实上，每个团队都会在同一个存储库中处理一个完全不同的子系统，这让我觉得它更糟糕。
我们目前的StarTeam流程适用于任何变更：
就个人而言，我认为“锁定”文件的想法是荒谬的。团队之间应该有足够的沟通，这样你就不需要了。
这里有没有人在类似大小的项目上有分布式存储库的经验？您能对版本控制和/或变更管理解决方案提出任何建议吗？主要要求是系统能够管理客户发起的变更请求，并强制开发人员将他们的签到链接到一个。
感谢。
答案 0 :(得分：4)
Git和Mercurial都被用于复杂程度远高于你提到的项目。因此，对您的项目团队规模使用Git / Mercurial应该不是问题。
本质上，我们希望对版本控制服务器进行更多控制。因此，颠覆很受欢迎。
使用像Mercurial或Git这样的DVCS，基于变更集来维护版本是多么容易。
您可以设置回购设置，仅在审核后推送更改集。这应该可以减轻变更经理的要求。
DVCS确实具有以下优势：您可以轻松地创建实验分支或克隆，如果它不起作用则将它们丢弃，并在您认为它们准备好进入黄金时段时将其拉出来。经常提交/早期提交是一种适用于DVCS的做法，因为您将更改推送到您自己的仓库。烘焙后，您可以将其向上推，以便团队内部可用。
锁定文件是一个古老的时代。它甚至没有像Subversion这样的工具使用。这确实是工作的障碍。
答案 1 :(得分：4)
我们用git成功完成了这项工作。我们遵循这个过程。很容易跟踪任何问题的进展：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
如果你看一下评论，就会有一些有影响力的人看过这个过程。这是一种很棒的工作方式，希望这篇文章可以为你提供所需的弹药。对于TFS特定的东西，请看一下：
答案 2 :(得分：3)
Git不会提供您正在寻找的“变更管理”流程。这是商业版本控制系统喜欢通过广告来吸引具有闪亮对象的企业的管理要求之一。这并不意味着你不能这样做，它只是在git的目的范围之外。很像，身份验证和访问控制（你可以使用ssh和gitolite，但git本身不提供这些服务）。除非您使用常见的错误跟踪工具，否则您可能需要自己开发此集成。
锁定文件总是错误的。这就是“合并”的目的。
我目前在10个开发人员的代码库上工作了大约200,000行代码，git工作得非常好。我们在其他项目中使用git也有一个数量级更大的组。 Git的优势在于合并，这就是它如何处理多个开发人员和许多提交。请记住，每次推送都是git的合并，无论它是否合适。您的本地存储库可能有一个名为master的分支，但它与中央存储库中的master不同。要同步它们，您需要进行合并，有时只是“快进合并”。
我们不想强迫改变请求的强大链接。当我考虑编写一个接口来执行此操作时，我遇到的一个问题是如何让哑跟踪系统知道错误所在的每个分支。一个简单的钩子是不够的。
您应该转向git以进行开发过程改进。对我来说，它从根本上改变（改进）我编写代码的方式。如果没有来自昂贵的IBM工具的所有预先打包的项目符号，那么您将面临更好地在业务方面更好地管理变更管理的案例。真正的问题是，一旦你接受了git，你再也无法使用任何其他工具了，不管他们提出的商业案例有多好......
答案 3 :(得分：2)
我在评论中写了这篇文章，但我认为重要的是它值得一个完整的答案。
我是一名Mercurial顾问，当我与客户交谈时，他们经常要求“变更请求”和“变更管理”。当我告诉他们Mercurial 没有这样的想法时，他们会感到惊讶。像Git一样，Mercurial是一个专注的工具。它执行版本控制，并允许您在顶部定义工作流程。如果您愿意，可以根据变更请求对工作流程进行短语，但您不必这样做。
处理变更请求的典型方法是将它们放入某种问题跟踪器中。可以使用Mercurial中的命名分支或使用Git中的提交消息中的注释来完成将更改集与CR链接。当推送到中央服务器时，问题会被挂钩更新。
你提到处理不应该成为发布版本一部分的更改。最简单的方法是在知道变化稳定之前不要合并到主线。您仍然希望在分支上运行测试，因此您需要一个测试设置，您可以逐个测试每个分支。要测试分支之间的依赖关系，请暂时合并它们并对结果运行测试。您可以继续处理分支，随后的合并将很小。
最后，当你想要自己发布分支时，你将它合并到主线。
答案 4 :(得分：1)
以下是一个小型Web应用程序，可将StarTeam的项目转换为GIT存储库。
http://dl.dropbox.com/u/101447754/startgit.tar.gz
我的发展是因为在我的工作中决定迁移并给出任何没有先前研究工作的团队进行这样一个过程的可能性。
现在：
StartGIT es una sencilla herramienta para trabajar con Controladores de Versiones，su fin es poder convertir un repositorio en Starteam a GIT，para ello se hace uso del script“svnimporter-1.2-st”obtenido en“http：// www。 polarion.com/user/direct_register.php?dl=svnimporterst“：
Tener instalado： - GIT - git-svn - java - apache2
Pasos： - Descomprimir“startgit.zip” - Colocar la carpeta descomprimida“startgit”en el directorio“/ var / www /” - Abrir navegador web y colocar lasiguientedireccción“http：// localhost / startgit”
// --------------------------------------------- ----------------
StartGIT是一个简单的工具，其目的是将Starteam存储库转换为GIT。
此脚本使用“svnimporter-1.2-st”获得“http://www.polarion.com / user / direct_register.php？dl = svnimporterst”
已安装： - GIT - Git-svn - java - apache2
步骤： - 解压缩“startgit.zip” - 将解压缩的文件夹“startgit”放在“/ var / www /”中 - 打开网络浏览器和“http：// localhost / startgit”
答案 5 :(得分：1)
StarTeam目前有一个git远程助手，它也可用于将StarTeam的历史记录导入git存储库，该存储库可以替代StarTeam。
代码位于https://github.com/warrenfalk/git-st/tree/st_to_git_migration_features（它是git-st的一个分支，其功能分支能够执行此类导入。分支是st_to_git_migration_features。）
请参阅：https://github.com/warrenfalk/git-st/blob/st_to_git_migration_features/README.migration.md以获取有关如何完成此操作的说明。
我用它来成功将StarTeam的历史记录导入git存储库。