5

我们目前正在为我们的项目使用 StarTeam，并且许可证即将到期。我们正在考虑迁移到 Team Foundation Server 或类似的东西，但有一个推动力（主要来自我和其他人）迁移到某种形式的分布式版本控制。问题之一是我们的变更经理希望能够通过变更请求跟踪和发布（如在 StarTeam 中），我不相信这可以通过开箱即用的 Mercurial 或 Git 轻松完成（请如我错了请纠正我）。

这是一个 15 年以上的产品，拥有数千个 java 文件和 PL/SQL 包，由 5-6 个开发子团队维护，总共有 30-40 名开发人员。对我来说，这似乎会使分布式存储库成为“尽早提交，经常提交”心态的噩梦。事实上，每个团队都在同一个存储库中开发完全不同的子系统，这在我看来更加糟糕。

我们当前针对任何变更的 StarTeam 流程如下：

  1. 锁定您要处理的文件，
  2. 进行全部更改并从网络驱动器上的副本中对其进行审核，
  3. 签入（并解锁）更改的文件，希望没有人强行破坏您的锁，
  4. 希望您的更改没有破坏从其他人更改到其他文件的构建

就个人而言，我认为“锁定”文件的想法是荒谬的。团队之间应该有足够的沟通，这样你就不需要了。

这里有没有人有类似规模项目的分布式存储库的经验？您能否就版本控制和/或变更管理解决方案提出任何建议？主要要求是系统能够管理客户发起的变更请求，并强制开发人员将他们的签入链接到一个。

谢谢。

4

6 回答 6

4

Git 和 Mercurial 都被用于复杂性远大于您提到的项目的项目。因此，针对您的项目团队规模使用 Git / Mercurial 应该不是问题。

从本质上讲，我们希望对版本控制服务器进行更多控制。因此，Subversion 非常受欢迎。

使用 DVCS（如 Mercurial 或 Git）维护基于变更集的版本是多么容易。

您可以有一个 repo 设置，其中仅在审查后才推送更改集。这应该可以减轻变更经理的要求。

DVCS 确实具有您可以轻松创建实验性分支或克隆的优势，如果它不起作用，则将其丢弃，并在您认为它们已准备好迎接黄金时段时将其拉入。经常提交/提早提交是一种适用于 DVCS 的做法，因为您将更改推送到自己的存储库。烘烤完成后，您可以将其向上推以在团队中使用。

锁定文件是一个古老的时代。即使像 Subversion 这样的工具也没有使用它。这确实是工作的障碍。

于 2011-12-06T23:55:00.600 回答
4

Git 不会提供您正在寻找的“变更管理”过程。这是商业版本控制系统喜欢宣传以吸引具有闪亮对象的企业的管理要求之一。这并不意味着你不能这样做，它只是在 git 的目的之外。很像，身份验证和访问控制（您可以使用 ssh 和 gitolite，但 git 本身不提供这些服务）。除非您使用常见的错误跟踪工具，否则您可能需要自己开发此集成。

锁定文件总是错误的。这就是“合并”的目的。

我目前与 10 名开发人员一起处理约 200,000 行代码的代码库，并且 git 运行良好。我们在其他项目中也使用 git 的组大一个数量级。Git 的优势在于合并，这就是它处理多个开发人员和大量提交的方式。请记住，每次推送都是 git 中的合并，无论它看起来是否像。您的本地存储库可能有一个名为 的分支master，但它master与中央存储库中的分支不同。要同步它们，您可以进行合并，有时只是“快进合并”。

我们不会费心强加一个强链接来更改请求。当我考虑编写一个接口来执行此操作时，我遇到的一个问题是如何让愚蠢的跟踪系统知道错误所在的每个分支。一个简单的钩子是不够的。

您应该转移到 git 以改进开发过程。对我来说，它从根本上改变（改进）了我编写代码的方式。您将面临的挑战是提出一个案例，让 git 在商业语言中更好地进行变更管理，而无需使用来自昂贵 IBM 工具的所有预先打包的项目符号。真正的问题是，一旦你接受了 git，你将永远无法再使用任何其他工具，无论它们提供了多么好的商业案例......

于 2011-12-07T00:02:59.497 回答
4

我们使用 git 非常成功地做到了这一点。我们遵循这个过程。很容易跟踪任何问题的进展：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

如果您查看评论，就会发现一些有影响力的人查看了该过程。这是一种很棒的工作方式，希望这篇文章能给你提供所需的弹药。对于 TFS 特定的东西，看看这里：

TFS 分支，有什么好处（误导性标题）

于 2011-12-07T00:03:21.637 回答
3

我在评论中写了这个，但我认为它足够重要，值得一个完整的答案。

我是一名 Mercurial 顾问，当我与客户交谈时，他们经常会询问“变更请求”和“变更管理”。当我告诉他们 Mercurial没有这样的想法时，他们感到很惊讶。与 Git 一样，Mercurial 是一个专注的工具。它进行版本控制，并允许您在顶部定义工作流。如果您愿意，您可以根据更改请求来表述工作流程，但您不必这样做。

处理变更请求的典型方法是将它们放入某种问题跟踪器中。可以使用 Mercurial 中的命名分支或在 Git 中使用提交消息中的注释来将变更集与 CR 链接起来。当推送到中央服务器时，问题由钩子更新。

您提到处理毕竟不应该成为发布一部分的更改。最简单的方法是在知道变化稳定之前不要合并到主线中。您仍然希望在分支上运行测试，因此您需要一个测试设置，您可以在其中逐个测试每个分支。为了测试分支之间的依赖关系，您暂时合并它们并在结果上运行测试。您可以继续在分支上工作，后续合并将很小。

最后，当您想承诺发布分支时，您可以将其合并到主线中。

于 2011-12-16T10:12:02.330 回答
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 存储库中。

于 2013-03-12T20:07:12.537 回答
1

以下是将 StarTeam 的项目转换为 GIT 存储库的小型 Web 应用程序。

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 coloura descomprimida "startgit" en el Directorio "/var/www/" - Abrir navegador web y colocar la siguiente direccció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”

于 2012-10-22T23:25:57.100 回答