企业中基于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

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

企业环境中的DVCS与CVCS:

我不会在这里讨论一般的利弊,而是关注你的背景.通常的概念是,使用DVCS需要比使用集中式系统更有纪律的团队.这是因为集中式系统为您提供了一种简单的方法来强制执行您的工作流程,使用分散式系统需要更多的沟通和纪律,以坚持既定的惯例.虽然这看起来似乎会导致开销,但我认为增加沟通的好处是使其成为一个好的过程.您的团队需要就一般的代码,变更和项目状态进行沟通.

纪律背景下的另一个方面是鼓励分支和实验.以下是Martin Fowler最近关于版本控制工具的 bliki条目的引用,他已经找到了对这种现象的非常简洁的描述.

DVCS鼓励快速分支进行实验.你可以在Subversion中做分支,但是所有人都可以看到它们不鼓励人们为实验工作开辟一个分支.类似地,DVCS鼓励检查工作:将未完成的更改(甚至可能无法编译或通过测试)提交到本地存储库.你可以在Subversion的开发者分支上做到这一点,但是这样的分支在共享空间中的事实使得人们不太可能这样做.

DVCS支持灵活的工作流程,因为它们通过有向无环图(DAG)中的全局唯一标识符而不是简单的文本差异来提供变更集跟踪.这允许他们透明地跟踪变更集的来源和历史,这可能非常重要.

工作流程:

Larry Osterman(一个致力于Windows团队的微软开发人员)有一篇关于他们在Windows团队中使用的工作流程的博客文章.最值得注意的是他们有:

• 一个干净,高品质的代码主干(主回购)
• 所有开发都发生在功能分支上
• 功能团队有团队回购
• 他们会定期将最新的主干更改合并到其功能分支中(Forward Integrate)
• 完整的功能必须通过几个质量门,例如审查,测试覆盖,问答(自己的回购)
• 如果某个功能已完成且质量可接受,则会将其合并到主干中(反向集成)

正如您所看到的,让每个存储库都可以独立存在,您可以将不同的团队分开,以不同的速度前进.此外,实现灵活质量门系统的可能性将DVCS与CVCS区分开来.您也可以在此级别解决您的权限问题.只允许少数人访问主仓库.对于层次结构的每个级别,请使用具有相应访问策略的单独仓库.实际上,这种方法在团队层面上可以非常灵活.您应该让每个团队决定他们是否希望在他们自己之间分享他们的团队回购,或者他们是否想要更加层次化的方法,只有团队负责人可以承诺团队回购.

(图片是从Joel Spolsky的hginit.com上偷来的.)

有一点需要说明的是: - 尽管DVCS提供了很好的合并功能,但这绝不是使用持续集成的替代品.即使在那时你也有很大的灵活性:主干回购的CI,团队回购的CI,Q&A回购等.

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),一流的合并/ vdiff工具集成
• 非常一致的界面,轻松过渡svn用户
• 可以做git也可以做的大部分事情,但提供更清晰的抽象.危险的操作总是明确的.通过必须明确启用的扩展提供高级功能.
• selenic 提供商业支持.

简而言之,在企业中使用DVCS时,我认为选择引入摩擦最小的工具非常重要.为了使转变成功,考虑开发人员之间不同的技能(关于VCS)尤为重要.

减少摩擦:

好吧,因为你似乎真的陷入困境,恕我直言还有两个选择.没有工具可以减少git的复杂性; git 很复杂.要么你面对这个或在git周围工作: -

1. 获得整个团队的git入门课程.这应该包括基础知识和一些练习(重要!).
2. 将主回购转换为svn并让"年轻明星" git-svn.这为大多数开发人员提供了一个易于使用的界面,可以弥补团队中缺乏的纪律,而年轻的明星可以继续使用git进行自己的回购.

说实话,我认为你真的有人的问题,而不是工具问题.有什么办法可以改善这种情况？

• 您应该清楚地表明您认为当前的流程最终将具有可维护的代码库.
• 投入一些时间进行持续整合.如上所述,无论您使用哪种VCS,都不会替代CI.你说有人把垃圾扔到主回购中:让他们修理他们的废话,同时红色警报响起并责备他们打破构建(或不符合质量指标或其他).

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

是的,我知道,Linus从未打算这样做.

实际上,Linus认为集中式系统是行不通的.

而且,独裁者和副官的工作流程有什么问题？

记住,git是一个分布式系统; 不要试图像中央一样使用它.

(更新)

如果你不试图使用git就好像它是"svn on steroids"(因为它不是),你的大多数问题都会消失.

而不是使用裸存储库作为中央服务器,每个人都可以推送(并可能搞砸),设置一些处理合并的集成管理器,这样只有他们可以推送到裸存储库.

通常这些人应该是团队领导者:每个领导者都会整合他自己团队的工作并将其推送到受祝福的存储库.

更好的是,其他人(即独裁者)从团队领导者那里撤出并将他们的变化集成到受祝福的存储库中.

这个工作流程没有任何问题,但我们是一个过度工作的创业公司,需要我们的工具来代替人类的时间和注意力; 没有人拥有甚至做代码审查的带宽,更不用说是仁慈的独裁者了.

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

做git pulls并不需要那么多时间.

git pull A
git pull B
git pull C

git 确实取代了人类的时间和注意力; 这就是为什么它首先写的原因.

• GUI工具还不成熟

gui工具可以很好地处理基本的东西.

高级操作需要编码器/书呆子的心态(例如,我很乐意从命令行工作).掌握概念需要一些时间,但并不难.

• 使用命令行工具,很容易搞砸合并并删除其他人的更改

除非您有许多不称职的开发人员对"中央存储库"具有完全写入权限,否则这不会成为问题.

但是,如果您设置工作流程以便只有少数人(集成商)写入"祝福"存储库,那将不会成为问题.

Git并不容易搞砸合并.

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

使用svn或任何其他(非dsitributed)工具也可以很容易地删除其他人的代码.实际上,使用这些其他工具会更容易,因为您倾向于"长时间坐在变化",并且在某些时候合并会变得非常困难.

而且因为这些工具不知道如何合并,所以最终总是需要手动合并.例如,只要有人提交您正在本地编辑的文件,就会将其标记为需要手动解决的冲突; 现在这是一场维护噩梦.

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

如果有人在解决合并冲突时消除了其他人的变化,那就不会是错误的:它可能是因为它是冲突解决所必需的,或者是因为他们不知道他们在做什么.

• 除了全局只读或读写权限之外,它不提供每用户存储库权限

• 如果您拥有存储库的任何部分的权限,那么您可以对存储库的每个部分执行相同的操作,因此您无法执行类似于在其他人无法在中央服务器上创建小组跟踪分支的操作一塌糊涂.

• 除了"任何事情"或"仁慈的独裁者"之外的工作流程很难鼓励,更不用说强制执行了

当你停止尝试使用git时,这些问题就会消失,就像它是一个集中式系统一样.

• 目前尚不清楚是否最好使用一个大型存储库(让每个人都搞乱所有东西)或大量的每个组件存储库(这会让人头疼,试图同步版本).

判决电话.

你有什么样的项目？

例如:项目A的版本xy是否完全取决于项目B的版本wz,这样每次检查项目A的xy时,你还必须检查项目B的wz,否则它将无法构建？如果是这样的话,我会将项目A和项目B放在同一个存储库中,因为它们显然是单个项目的两个部分.

这里的最佳做法是使用你的大脑

• 对于多个存储库,还不清楚如何通过从中央存储库中提取来复制其他人拥有的所有源,或者做到像昨天下午4:30那样获取所有内容的事情.

我不确定你是什么意思.

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与Git插件一起使用,没有任何其他东西.大多数Linux开发人员也使用CLI git客户端,没有任何问题.一些Mac开发人员成功使用Tower Git.请注意,这些客户端都不能阻止用户"搞乱"中央存储库:需要服务器端控制机制

服务器访问控制和集成

如果你想避免开发人员"弄乱"你的Git存储库,你需要选择一个解决方案:

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

没有那么多现成的服务器端解决方案可以帮助这个,我建议你看看其中一个:

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

希望这可以帮助!