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

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

但是现在它必须在工作中，坦率地说，我们遇到了问题。

开箱即用，git似乎不适用于大型（20+开发人员）组织中的集中开发，该组织具有不同能力和git复杂程度的开发人员-尤其是与Perforce或Subversion等其他源代码控制系统相比，git针对这种环境。（是的，我知道，Linus从未打算这样做。）

但是-由于政治原因-我们仍然坚持使用git，即使它因我们试图使用它而糟透了。

以下是我们看到的一些内容：

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

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

如果您处在这种情况下-或者您通常拥有一些工具，技巧和窍门，可以使在某些人不是命令行爱好者的大型组织中使用git更容易，更有效率-我很想听听您的想法建议。

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

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

在我工作的地方，除了git，我们什么都不能使用。这不是一个选择。我们坚持下去。我们不能使用mercurial，svn，bitkeeper，Visual Source Safe，ClearCase，PVCS，SCCS，RCS，集市，Darcs，单调，Perforce，Fossil，AccuRev，CVS甚至我在1987年使用的Apple优秀的ol'Projector。因此，尽管欢迎您讨论其他选项，但如果您不讨论git，就不会得到赏金。

另外，我还在寻找有关如何在企业中使用git的实用技巧。我把整个问题清单放在了这个问题的首位。同样，欢迎大家讨论理论，但如果您想获得赏金，请给我解决方案。

与普遍看法相反，我认为在企业环境中使用DVCS是理想的选择，因为它可以实现非常灵活的工作流程。我将首先讨论使用DVCS与CVCS的最佳实践，然后再讨论git。

企业环境中的DVCS与CVCS：

我不会在这里谈论一般的利弊，而是关注您的情况。通常的观念是，与使用集中式系统相比，使用DVCS需要更严格的团队。这是因为集中式系统为您提供了一种简便的方法来执行工作流，而使用分散式系统则需要更多的沟通和纪律以遵守约定。尽管这似乎在增加开销，但我认为增加沟通以使其成为一个良好的过程所带来的好处。您的团队通常需要就代码，变更和项目状态进行沟通。

学科方面的另一个方面是鼓励分支和实验。这是马丁·福勒（Martin Fowler）最近在版本控制工具上发表的bliki文章中的引文，他为这种现象找到了非常简洁的描述。

DVCS鼓励快速分支进行实验。您可以在Subversion中创建分支，但是所有人都可以看到它们的事实阻止了人们为实验工作打开分支。同样，DVCS鼓励检查点：将不完整的更改提交到本地存储库，甚至可能不会编译或通过测试。同样，您可以在Subversion的开发人员分支上执行此操作，但是这样的分支位于共享空间中的事实使人们不太可能这样做。

DVCS支持灵活的工作流程，因为它们通过有向非循环图（DAG）中的全局唯一标识符而不是简单的文本差异提供了变更集跟踪。这使他们可以透明地跟踪变更集的起源和历史，这可能非常重要。

工作流程：

拉里·奥斯特曼（Larry Osterman，Windows团队的一名Microsoft开发人员）撰写了一篇很棒的博客文章，介绍了他们在Windows团队中使用的工作流程。最值得注意的是，它们具有：

• 干净，高质量的仅代码中继（主存储库）
• 所有开发都发生在功能分支上
• 特色团队有团队回购
• 他们会定期将最新的主干更改合并到其功能分支中（Forward Integrate）
• 完整的功能必须通过多个质量关卡，例如审查，测试覆盖范围，问题与解答（自行回购）
• 如果功能已完成且质量可接受，则将其合并到主干（反向集成）中

如您所见，让这些存储库中的每一个独立存在，您可以使以不同速度前进的不同团队脱钩。同样，实施灵活的质量门系统的可能性也将DVCS与CVCS区别开来。您也可以在此级别解决许可问题。应该只允许少数人访问主存储库。对于层次结构的每个级别，都有一个单独的回购以及相应的访问策略。实际上，这种方法在团队级别上可以非常灵活。您应该让每个团队决定是否要在他们之间共享他们的团队回购协议，或者他们是否需要一种更具层次性的方法，即只有团队负责人才能提交给团队回购协议。

（图片从Joel Spolsky的hginit.com中被盗。）

在这一点上，还有一点要说：-尽管DVCS提供了强大的合并功能，但这绝不能替代使用持续集成。即使到了那时，您仍然具有很大的灵活性：用于中继仓库的CI，用于团队仓库的CI，问与答仓库等。

在企业环境中的Git：

正如您已经指出的，Git可能不是针对企业环境的理想解决方案。重复您的一些担忧，我认为最值得注意的是：

• Windows上仍不成熟的支持（如果最近更改，请纠正我）现在Windows具有github Windows客户端，tortoisegit和atlassian的SourceTree
• 缺乏成熟的GUI工具，没有一流的公民vdiff /合并工具集成
• 界面不一致，内部运行情况下的抽象水平非常低
• SVN用户的学习曲线非常陡峭
• Git非常强大，可以轻松修改历史记录，如果您不知道自己在做什么，这将非常危险（有时，即使您以为自己知道，也会很危险）
• 没有可用的商业支持选项

我不想在这里开始git vs. hg Flamewar，您已经通过切换到DVCS来完成正确的步骤。Mercurial解决了以上几点，因此我认为它更适合于企业环境：

• 支持运行python的所有平台
• 所有主要平台上的出色GUI工具（win / linux / OS X），一流的merge / vdiff工具集成
• 界面非常一致，便于SVN用户过渡
• 可以做git可以做的大多数事情，但是提供了更简洁的抽象。危险操作总是很明显的。通过必须明确启用的扩展名提供高级功能。
• 可从selenic 获得商业支持。

简而言之，在企业中使用DVCS时，我认为选择一种引入摩擦最小的工具很重要。为了使转换成功，考虑开发人员之间不同的技能（就VCS而言）尤其重要。

减少摩擦：

好的，由于您似乎确实对这种情况感到困惑，因此恕我直言还有两个选择。没有工具可以使git变得不那么复杂。git 很复杂。您要么面对这个问题，要么解决git：

1. 获得整个团队的git入门课程。这应该仅包括基础知识和一些练习（重要！）。
2. 将主仓库转换为svn，然后让“年轻星星” git-svn。这为大多数开发人员提供了易于使用的界面，并可以弥补团队中缺乏纪律的人，而年轻的明星们可以继续使用git来存储自己的仓库。

老实说，我认为您确实遇到了人员问题而不是工具问题。如何改善这种情况？

• 您应该清楚地表明，您认为当前的过程将以可维护的代码库结束。
• 花一些时间进行持续集成。如上文所述，无论您使用哪种VCS，都无法替代CI。您说过有人将废话推入主仓库：在红色警报响起时让他们修复废话，并责怪他们破坏了构建（或未达到质量指标或其他要求）。

我是一家相当大的开发组织的SCM工程师，并且在过去大约一年的时间里，我们从svn转换为git。我们以集中方式使用它。

我们使用gitosis托管存储库。由于git的分支单位基本上是存储库，因此我们将整体的svn存储库分为许多较小的git存储库。（有很多解决方法，但是它们很尴尬。）如果要按分支访问控制，则使用gitolite可能是更好的方法。如果您愿意花钱的话，还有一个内部版本的GitHub。就我们的目的而言，gitosis很好，因为我们对存储库拥有相当开放的权限。（我们有一群人可以对存储库组进行写访问，每个人都可以对所有存储库进行读访问。）我们将gitweb用于Web界面。

至于您的一些特定问题：

• 合并：您可以使用自己选择的可视合并工具；各地都有关于如何进行设置的说明。在我看来，您可以进行合并并在本地存储库上完全检查其有效性，这是git的主要优点；您可以在推送任何内容之前验证合并。
• GUI：我们有几个人在使用TortoiseGit，但我并不推荐这样做；它似乎以奇怪的方式与命令行交互。我必须同意，这是一个需要改进的领域。（也就是说，我一般不喜欢GUI进行版本控制。）
• 小组跟踪分支：如果使用提供更细粒度的ACL的东西（如gitolite），这样做很容易，但是您也可以通过连接各个开发人员的本地存储库来创建共享分支-git repo可以具有多个远程站点。

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

是的，我知道，Linus从未打算这样做。

实际上，Linus认为，集中式系统无法正常工作。

而且，独裁者和选民的工作流程怎么了？

记住，git是一个分布式系统。不要试图像中央那样使用它。

（更新）

如果您不尝试使用git就像“在类固醇上使用svn”（因为不是），大多数问题将消失。

与其将裸仓库用作所有人都可以推送（并可能破坏）的中央服务器，不如设置一些处理合并的集成管理器，以便只有他们才能推送到裸仓库。

通常，这些人应该是团队的领导者：每位领导者都将自己团队的工作整合到一起，并推送到有福的仓库中。

更好的是，其他人（即独裁者）从团队负责人那里汲取了灵感，并将他们所做的更改集成到了受祝福的资源库中。

该工作流程没有任何问题，但是我们是一家工作过度的初创公司，需要我们的工具来代替人类的时间和精力。没有人有足够的带宽进行代码审查，更不用说仁慈的独裁者了。

如果集成商没有时间审查代码，那很好，但是您仍然需要有人来集成每个人的合并。

进行git pull并不需要那么多时间。

git pull A
git pull B
git pull C

混帐确实为人类的时间和精力替代; 这就是为什么它首先被编写的原因。

• GUI工具还不成熟

gui工具可以很好地处理基本内容。

高级操作需要编码者/书呆子的心态（例如，我很喜欢从命令行工作）。掌握这些概念需要花费一些时间，但并不难。

• 使用命令行工具，很容易搞乱合并并消除其他人的更改

除非您有许多不称职的开发人员具有对“中央存储库”的完全写入权限，否则这将不是问题。

但是，如果您设置工作流以便只有很少的人（集成商）写入“受祝福的”存储库，那将不是问题。

Git使得合并变得不容易。

当存在合并冲突时，git将清楚地标记冲突的行，以便您知道哪些更改是您的更改，哪些不是。

使用svn或任何其他（非分发的）工具清除其他人的代码也很容易。实际上，使用其他工具会更容易，因为您倾向于长时间“坐下来进行更改”，并且在某些时候合并可能会变得异常困难。

而且由于这些工具不知道如何合并，您最终总是必须手动合并事物。例如，一旦有人提交您要在本地编辑的文件，该文件就会被标记为冲突，需要手动解决；现在，这就是维护的噩梦。

使用git时，大多数时候不会有任何合并冲突，因为git实际上可以合并。在确实发生冲突的情况下，git会为您清楚地标记行，以便您确切知道哪些更改是您的以及哪些更改来自其他人。

如果某人在解决合并冲突时抹去了其他人的更改，那肯定不是错误的：要么是因为有必要解决冲突，要么是因为他们不知道自己在做什么。

• 它不提供超出全局只读或读写特权的每用户存储库权限

• 如果您对存储库的任何部分都具有权限，则可以对存储库的每个部分执行相同的操作，因此您不能做其他事情，例如在中央服务器上建立小组跟踪分支，而其他人则做不到搞砸了。

• 除了“无所不能”或“仁慈独裁者”以外的工作流程很难鼓励，更不用说强制执行了

当您停止尝试使用git就像集中式系统一样时，这些问题将消失。

• 尚不清楚使用单个大型存储库（让每个人都弄乱一切）还是使用大量每个组件的存储库（使尝试同步版本感到头痛）是否更好。

审判电话。

您有什么样的项目？

例如：项目A的版本xy是否完全取决于项目B的版本wz，以便每次您检查项目A的xy时，您还必须检出项目B的wz，否则它将无法生成？如果是这样，我将把项目A和项目B放在同一个存储库中，因为它们显然是单个项目的两个部分。

最好的做法是动脑筋

• 对于多个存储库，也不清楚如何通过从中央存储库中提取其他人来复制所有资源，或者如何做一些事情，例如从昨天下午4:30开始获取所有内容。

我不确定你是什么意思。

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

如果您决定使用Gerrit，我建议您尝试保持一段线性的历史记录，而不是像某些开放源代码人那样保持分支历史记录。Gerrit将其表述为“仅允许快速更改”。然后，您可以按惯常的方式使用分支和合并（对于发行版或其他版本）。

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

您在这里遇到的问题完全不同：

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

工作流程

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

客户工具

现在有几个选项可用，这是一个非常拥挤的区域。许多开发人员已成功将IntelliJ Idea和Eclipse与Git插件配合使用，而没有其他任何东西。同样，大多数Linux开发人员都在使用CLI git客户端，没有任何问题。一些Mac开发人员已成功使用Tower Git。请注意，这些客户端都不能阻止用户“访问”中央存储库：需要服务器端控制机制

服务器访问控制和集成

如果您想避免开发人员“弄乱”您的Git存储库，那么您实际上需要选择一种解决方案：

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

没有太多现成的服务器端解决方案可以帮助您解决此问题，我建议您查看以下方法之一：

• 奇妙的：它可以提供基本的访问级别安全性，但是缺少开箱即用的精细权限控制，因此您可能必须进行一些编码来处理诸如分支级别权限之类的方案。它还缺乏与现有公司身份验证机制的集成
• GitHub Enterprise：由GitHub最近发布，在您公司中具有GitHub。它缺乏SOX兼容性和细粒度的安全性
• Gerrit：它可以提供精细的访问级别安全性并与公司身份验证系统集成，但是缺少SOX合规性和SSO。另外，某些操作只能通过CLI通过SSH进行
• GitEnterprise：它提供分支机构级别的权限，SSO，SOX遵从性，基于Web的全面管理。最近它还与Gerrit集成在一起，因此它还为您提供了完整的Gerrit实例。

希望这可以帮助！

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

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

总的来说，我坚决选择在以下方面支持细粒度访问控制的工具：-分支（为了将具有严格安全性的稳定发行分支与需要更多敏捷性和灵活性的主题分支隔离开来）-身份实施（作者/提交者） ）。这是SOX的关键 -git命令限制-审计跟踪。这是SOX的关键

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

1. Gerrit代码审查（http://code.google.com/p/gerrit/）
2. GitEnterprise（http://gitenterprise.com）
3. CollabNet TeamForge（http://www.collab.net/gotgit），在幕后使用Gerrit 2.1.8

PS 不要低估SOX和CMMI的合规性：很多时候，您的选择范围有限，取决于公司企业安全性策略。

希望这可以帮助。

卢卡

我们最近从svn切换到git。由于git-daemon不适用于msysgit，因此我们选择了在具有gitosis的Linux服务器上使用中央存储库方法。

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

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

我们还担任第二级服务台的轮换角色，至少对我们而言，工作量如此大，以至于可以同时担任两个角色。

由于没有母版，这是一个好处，没有经过发行管理器就无法向项目中添加任何代码，因此我们直接发现了以前在项目中静默添加了多少代码。

审查过程始于分支机构所有者将差异提交到审查板，并在白板上贴上绿色的便利贴，并在“审查”下标明分支机构名称（我们有基于看板的工作流程），或者如果它是已完成用户的一部分故事，将整个故事卡移至“供审核”，并在上面贴上邮戳。发行经理是将卡片和贴子移到“准备测试”的人，然后产品所有者可以选择在下一个测试版本中插入哪个卡片。

进行合并时，版本管理器还应确保合并提交具有明智的提交消息，该消息可以在变更日志中用于产品所有者。

将发行版投入生产后，该标签将用作分支的新基础，所有现有分支都将与之合并。这样，所有分支都有一个共同的父代，这使得合并变得更容易。

我还将添加“您是否考虑过”的帖子。

集市的伟大之处之一就是它的灵活性。这是它击败所有其他分布式系统的地方。您可以在集中式模式，分布式模式下操作Bazaar，或获得以下两种功能：（这意味着开发人员可以选择自己喜欢的模型或最适合其工作组的模型）。您还可以在旅途中断开集中式存储库，并在回来时重新连接。

最重要的是，出色的文档和使您的企业满意的东西：商业支持。

• 安装一个不错的Web界面，例如Github FI
• 坚持相对集中的模型（最初）以使人们感到舒适。
• 为每个共享分支运行一个持续集成版本。
• 共享一组不错的全局git config选项。
• 通过bash完成和当前分支的提示将git集成到您的shell中。
• 尝试将IntelliJ的Git集成作为合并工具。
• 确保适当地使用.gitignore。

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

无论是否有政治，Git都是DCVS的最佳选择。像任何强大的工具一样，值得花一点时间来了解该工具的设计原理，为此，我强烈推荐Pro Git书。从长远来看，花几个小时可以节省很多挫败感。

界面：目前，TortoiseGit v1.7.6对于大多数日常操作来说应该还不错。记录，提交，推入，拉入，获取，比较，合并，分支，Cherry-pick，变基，标记，导出，存储，添加子模块等...本身也支持x64

为了在具有许多开发人员的开发团队中高效使用git，需要持续构建和测试的CI系统。詹金斯（Jenkins）提供了这种工具，我强烈建议您这样做。无论如何，都必须完成集成工作，并且尽早且更频繁地进行集成要便宜得多。

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

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

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