企业中基于Git的源代码控制：建议的工具和实践？

Question

我将git用于个人项目并认为它很棒。它快速，灵活，功能强大，适用于远程开发。

但现在它的工作是强制性的，坦率地说，我们遇到了问题。

开箱即用，git似乎不适合大型（20多个开发人员）组织的集中开发，开发人员具有不同的能力和git复杂程度 - 特别是与其他源控制系统（如Perforce）或Subversion，针对那种环境。 （是的，我知道，Linus从未打算这样做。）

但是 - 出于政治原因 - 我们仍然坚持使用git，即使它很糟糕我们正试图用它做什么。

以下是我们看到的一些事情：

• GUI工具不成熟
• 使用命令行工具，很容易搞砸合并并删除其他人的更改
• 它不提供超出全局只读或读写权限的每用户存储库权限
• 如果您拥有存储库的任何部分的权限，那么您可以对存储库的每个部分执行相同的操作，因此您无法执行类似于在其他人的中央服务器上创建小组跟踪分支的操作不能搞砸。
• 除了“任何事情”或“仁慈的独裁者”以外的工作流程很难鼓励，更不用说强制执行了
• 目前尚不清楚是否最好使用一个大型存储库（让每个人都搞乱一切）或大量的每个组件存储库（这会让人头疼，试图同步版本）。
• 对于多个存储库，还不清楚如何通过从中央存储库中提取来复制其他人拥有的所有源，或者做到像昨天下午4:30那样获取所有内容的事情。

但是，我听说人们在大型开发组织中成功使用git。

如果您处于这种情况 - 或者您通常拥有工具，提示和技巧，以便在一个大型组织中使用git变得更容易和更有效率，而某些人不是命令行粉丝 - 我很乐意听到你有什么建议。

顺便说一下，我已经在LinkedIn上问过这个问题的一个版本了，并没有得到真正的答案，但很多“天哪，我也很想知道这个！”

更新：让我澄清......

在我工作的地方，我们不能使用除git之外的任何东西。这不是一个选择。我们坚持下去。我们不能使用mercurial，svn，bitkeeper，Visual Source Safe，ClearCase，PVCS，SCCS，RCS，bazaar，Darcs，monotone，Perforce，Fossil，AccuRev，CVS，甚至是我在1987年使用的Apple的好投影仪。因此，虽然欢迎您讨论其他选项，但如果您不讨论git，那么您将无法获得赏金。

另外，我正在寻找关于如何在企业中使用git的实用技巧。我在这个问题的顶部列出了一系列我们遇到过的问题。同样，欢迎人们讨论理论，但如果你想获得赏金，请给我解决方案。

Answer 1

Answer 2

我是一个相当大的开发组织的SCM工程师，我们在过去一年左右从svn转换为git。我们以集中的方式使用它。

我们使用gitosis来托管存储库。我们将单片svn存储库拆分为许多较小的git存储库，因为git的分支单元基本上是存储库。 （有很多方法，但它们很尴尬。）如果你想要每种分支的访问控制，gitolite可能是一种更好的方法。如果您愿意花钱，还有GitHub内部的防火墙版本。出于我们的目的，gitosis很好，因为我们对我们的存储库拥有非常开放的权限。 （我们拥有对存储库组具有写访问权限的人员组，每个人都具有对所有存储库的读访问权。）我们将gitweb用于Web界面。

至于你的一些具体问题：

• 合并：您可以使用您选择的可视化合并工具;各个地方都有关于如何设置它的说明。在我看来，你可以完全合并并在你的本地回购中检查其有效性这一事实对git来说是一个重要的优势;你可以在推送任何东西之前验证合并。
• 图形用户界面：我们有几个人使用TortoiseGit，但我并不真的推荐它;它似乎与命令行以奇怪的方式进行交互。我必须同意这是一个需要改进的领域。 （也就是说，我不是一般的版本控制GUI的粉丝。）
• 小组跟踪分支：如果您使用提供更细粒度的ACL（如gitolite）的东西，这很容易做到这一点，但您也可以通过连接各种开发人员的本地存储库来创建共享分支 - git repo可以拥有多个遥控器。

我们切换到git是因为我们有很多远程开发人员，因为我们在Subversion上遇到了很多问题。我们仍在尝试工作流程，但目前我们基本上使用的方式与我们以前使用Subversion的方式相同。我们喜欢它的另一件事是它开辟了其他可能的工作流程，例如使用分段存储库进行代码审查和在小组之间共享代码。它还鼓励很多人开始跟踪他们的个人脚本等等，因为创建存储库非常容易。

Answer 3

Answer 4

我强烈建议您http://code.google.com/p/gerrit/进行企业工作。它为您提供访问控制以及基于内置审阅的工作流程。它针对任何LDAP系统进行身份验证。您可以使用http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin将其连接到Hudson，让您在仍在审核期间构建和测试更改;这是一个非常令人印象深刻的设置。

如果您决定使用gerrit，我建议您尝试保持一个非常线性的历史，而不是像一些开源人员那样的分支历史。 Gerrit将此短语称为“仅允许快进更改”。然后，您可以使用更多的方式使用分支和合并，以及发布和诸如此类的东西。

Answer 5

我根据我在一家大型电信公司担任开发经理的经历回答了这个问题，我们在2010年采用了Git

这里有一系列不同的问题：

• 工作流程
• 客户端工具
• 服务器访问控制和集成

<强>工作流

我们成功采用了中央存储库模式：我们在企业项目中拥有的（500万用户群的大型门户网站）是一个事实上的中央存储库，可以生成官方版本，然后通过交付流程（在我们的例子中，由三个级别的测试和两个部署组成）。每个开发人员都管理自己的仓库，我们按照每个功能进行分支。

客户端工具

现在有几种选择，现在这是一个非常拥挤的领域。许多开发人员成功使用IntelliJ Idea和Eclipse with the Git plugin，没有任何其他内容。大多数Linux开发人员也使用CLI git客户端，没有任何问题。一些Mac开发人员成功使用Tower Git。请注意，这些客户端都不能阻止用户“搞乱”中央存储库：需要服务器端控制机制

服务器访问控制和集成

如果你想避免开发人员“弄乱”你的Git存储库，你需要选择一个解决方案：

• 公开了一个体面的网络管理界面来完成每项操作
• 允许您强制执行用户身份（使用“裸”Git存储库非常容易代表其他人提交）
• 为您提供细粒度的安全性（例如，您可以阻止FORCE-PUSH并将某些分支设置为仅对某些开发人员/组进行读取）
• 与您的企业身份验证系统（即LDAP，Windows ActiveDirectory）集成
• 为您提供全面审核（SOX合规有时非常对大型企业非常重要）

没有那么多现成的服务器端解决方案可以帮助解决这个问题，我建议您查看其中一个：

• Gitorious：它可以提供基本的访问级别安全性，但它缺乏开箱即用的细粒度权限控制，因此您可能需要进行一些编码来处理分支级别权限等方案。它还缺乏与现有企业认证机制的集成
• GitHub企业版：最近由GitHub发布，它在您的公司中展示了GitHub。它缺乏SOX合规性和细粒度的安全性
• Gerrit：它可以提供良好的graind访问级别安全性并与企业身份验证系统集成，但它缺乏SOX合规性和SSO。此外，某些操作只能通过CLI通过CLI
完成
• GitEnterprise：它提供分支级别权限，SSO，SOX合规性，完全基于Web的管理。它最近还与Gerrit集成，因此它还为您提供了完整的Gerrit实例

希望这有帮助！

Answer 6

听起来您的问题是您尚未决定或制定工作流程。 Git足够灵活，可以像svn或任何其他VCS一样使用它，但它非常强大，如果你没有建立每个人必须遵循的规则，那么你最终会陷入混乱。我会推荐上面提到的独裁者 - 中尉工作流程，但结合Vincent Driessen描述的分支模型。有关详细信息，请参阅这些截屏视频by David Bock，以及Mark Derricutt。

Answer 7

在工具上，MacOS-X用户发现GitX（http://gitx.frim.nl/）非常简单有效。缺点是不支持Git Client钩子（$ GIT_ROOT / .git / hooks下的钩子）。

总体而言，我强烈选择支持细粒度访问控制的工具： - 分支（为了将稳定版本分支与严格的安全性分离，需要更高的灵活性和灵活性的主题分支） - 身份执行（作者/提交人）。 这是SOX的关键 - git命令限制 - 审计跟踪。 这是SOX的关键

我成功使用这些功能的是：

1. Gerrit Code Review（http://code.google.com/p/gerrit/)<< li>
2. GitEnterprise（http://gitenterprise.com）
3. CollabNet TeamForge（http://www.collab.net/gotgit），在幕后使用Gerrit 2.1.8

P.S。 不要低估SOX和CMMI合规性：很多时候，您的公司企业安全政策规定的选择范围有限。

希望这有帮助。

卢卡。

Answer 8

我们最近从svn切换到git。因为git-daemon不能与msysgit一起使用，所以我们在带有gitosis的Linux服务器上选择了一个中央存储库方法。

为了消除搞砸主人的可能性，我们简单地将其删除了。相反，我们通过合并选择用于测试的分支并标记合并来准备所有版本。如果它通过测试，则提交标记有版本并投入生产。

为了解决这个问题，我们有一个发布经理的轮流角色。发布经理负责在准备进行测试之前审核每个分支。然后，当产品拥有者决定是时候将已批准的分支捆绑在一起以进行新的测试发布时，发布经理会执行合并。

我们还拥有2级帮助台的旋转角色，至少对我们而言，工作量可以同时兼具两种角色。

作为没有掌握的好处，无法通过发布管理器向项目中添加任何代码，因此我们直接发现了之前默认添加到项目中的代码数量。

审核流程从分支所有者提交差异审核板开始，并在白板上放置一个绿色的帖子，其中包含分支名称（我们有一个基于看板的工作流程）在“for review”下，或者如果它是一个完整的用户故事，将整个故事卡移动到“进行审核”并将其放在上面。密码管理员是将卡片移动并将其发布到“准备测试”的人，然后产品所有者可以选择在下一个测试版本中包含哪些卡片。

在进行合并时，发布管理器还会确保合并提交具有合理的提交消息，该消息可以在产品所有者的更改日志中使用。

当一个版本投入生产时，标签将被用作分支的新基础，并且所有现有分支都与它合并。这样所有分支都有一个共同的父级，这使得更容易处理合并。

Answer 9

我也会添加“你考虑过”的帖子。

Bazaar的一大优点是它的灵活性。这是它击败所有其他分布式系统的地方。您可以在集中模式，分布式模式下运行Bazaar，或者获得：两者（意味着开发人员可以选择他们喜欢哪种模式或哪种模式最适合他们的工作组）。您还可以在旅途中断开集中式存储库，并在返回时重新连接。

最重要的是，优秀的文档和让您的企业满意的东西：提供商业支持。

Answer 10

• 安装一个体面的网络界面，例如Github FI
• 坚持相对集中的模式（最初）以保持人们的舒适。
• 为每个共享分支运行持续集成构建。
• 分享一组优秀的全局git配置选项。
• 将git集成到shell中，使用bash完成，并提示当前分支。
• 尝试使用IntelliJ的Git Integration作为合并工具。
• 请确保您.gitignore适当。

Answer 11

关于第3点和第3点4（每个用户，每个部分，每个分支的权限），请查看gitolite（在Pro Git书中介绍：http://progit.org/book/ch4-8.html）。

政治与否，Git是DCVS的最佳选择。像任何强大的工具一样，在理解工具如何设计工作方面需要花费一点时间，为此，我强烈推荐Pro Git书。从长远来看，花费几个小时就可以节省很多挫折。

Answer 12

GUI：目前，TortoiseGit v1.7.6对于大多数日常操作都应该没问题。 日志，提交，推，拉，取，差异，合并，分支，樱桃挑选，Rebase，标记，导出，藏匿，添加子模块等... 本身也支持x64

Answer 13

为了在拥有大量开发人员的开发团队中有效地使用git，需要一个可以持续构建和测试的CI系统。詹金斯提供这样的车辆，我强烈推荐。无论如何都必须完成整合工作，并且更早，更经常地做更便宜。

Answer 14

比gitosis或gitolite更适合协作开发，但开源是Gitorious。它是一个Ruby on Rails应用程序，它处理存储库和合并的管理。它应该解决你的许多问题。

Answer 15

Git允许创建私有分支。这鼓励开发人员经常提交，以便将修改分解为小提交。当开发人员准备发布他的更改时，他会推送到中央服务器。如果需要，他可以使用预提交脚本来验证他的代码。

Answer 16

恩智浦正在使用一个通用平台（企业级）管理Git和Subversion，将Android移动开发与传统软件项目集成：http://www.youtube.com/watch?v=QX5wn0igv7Q