企业中基于Git的源代码pipe理：build议的工具和实践？
我使用个人项目的git，认为这是伟大的。 它快速，灵活，function强大，对远程开发非常有用。
但是现在它在工作中被授权，坦率地说，我们遇到了问题。
开箱即用，git在大型（20+开发者）组织中集中开发并不适合开发人员，这些开发人员具有不同的能力和git复杂程度 – 尤其是与其他源代码控制系统（如Perforce或Subversion）相比，瞄准那种环境。 （是的，我知道，Linus从来没有这样做。）
但是 – 出于政治原因，即使我们正在试图用它做什么，我们也会被git困住。
以下是我们看到的一些事情：
- GUI工具还不成熟
- 使用命令行工具，很容易搞砸一个合并，并消除别人的变化
- 它不提供超出全局只读或读写权限的每用户存储库权限
- 如果您有权限访问存储库的任何部分，则可以对存储库的每个部分执行相同的操作，因此您无法在中央服务器上创build小组跟踪分支，而其他人无法做到这一点乱七八糟的。
- “任何事情都行”或“仁慈的独裁者”以外的工作stream很难鼓励，更不用说强制执行了
- 目前尚不清楚是否最好使用一个单一的大型资源库（可以让所有人都搞砸），或者是每个组件库有很多（这使得头版试图同步版本）。
- 有了多个版本库，也不清楚如何从中央库复制别人所有的源代码，或者在昨天下午4点半之前完成所有的工作。
但是，我听说有人在大型开发组织中成功地使用git。
如果你处在这种情况下 – 或者你通常有一些工具，技巧和诀窍，使得在一些大型组织中使用git变得更容易和更有效率，那里的一些人不是命令行的粉丝 – 我很想听听你有什么build议。
顺便说一句，我已经在LinkedIn上提出了这个问题的一个版本，并没有真正的答案，但很多“天哪，我也很想知道这个！”
更新：让我澄清…
在我工作的地方，我们不能使用除git之外的其他任何东西 。 这不是一个选项。 我们一直坚持下去。 我们不能使用1987年使用的mercurial，svn，bitkeeper，Visual Source Safe，ClearCase，PVCS，SCCS，RCS，市场，Darcs，单调，Perforce，Fossil，AccuRev，CVS，甚至苹果公司的好投影机。所以，当你欢迎讨论其他选项时， 如果你不讨论git ， 你将不会得到赏金。
另外，我正在寻找关于如何在企业中使用git的实用技巧 。 我在这个问题的顶部列出了一整套我们遇到的问题。 再次，人们欢迎讨论理论，但如果你想获得赏金，给我解决scheme。
根据共同意见，我认为使用DVCS是企业设置的理想select，因为它可以实现非常灵活的工作stream程。 我将首先讨论使用DVCS与CVCS，最佳做法，然后讨论git。
企业上下文中的DVCS vs. CVCS：
我不会谈论这里的一般优点/缺点，而是侧重于你的背景。 普遍认为，使用DVCS需要比使用集中式系统更有纪律的团队。 这是因为中央系统为您提供了一个简单的方法来执行您的工作stream程，使用分散系统需要更多的沟通和纪律来坚持已经build立的惯例。 虽然这看起来似乎导致了开销，但我认为增加沟通对于使其成为一个好的过程是必要的。 一般来说，您的团队需要就代码，变更和项目状态进行沟通。
纪律的另一个方面是鼓励分支和实验。 以下是Martin Fowler最近在版本控制工具上的bliki条目的一个引用，他已经find了这个现象的一个非常简洁的描述。
DVCS鼓励快速分支实验。 你可以在Subversion中做分支，但是它们对所有人都是可见的，这就阻碍了人们开放实验性工作的分支。 同样，DVCS鼓励检查工作：将不完整的更改提交给本地存储库，甚至不会编译或通过testing。 你也可以在Subversion的开发者分支上这样做，但是这样的分支在共享空间中的事实使得人们不太可能这样做。
DVCS支持灵活的工作stream程，因为它们通过有向无环图（DAG）中的全局唯一标识符提供变更集跟踪，而不是简单的文本差异。 这使得他们能够透明地追踪变更集的起源和历史，这一点非常重要。
工作stream程：
Larry Osterman（一位在Windows团队工作的微软开发人员）有一篇关于他们在Windows团队中使用的工作stream程的博文 。 最值得注意的是他们有：
- 干净，高品质的代码只有主干（主回购）
- 所有的开发发生在function分支上
- 特征团队有团队回购
- 他们经常将最新的主干更改合并到他们的function分支（ Forward Integrate ）
- 完整的function必须通过几个质量大门，如审查，testing覆盖面，问答（自己的回购）
- 如果某个function已经完成并且具有可接受的质量，则会合并到主干中（ Reverse Integrate ）
正如你所看到的，让这些存储库各自独立存在，你就可以把不同的团队分离出来。 此外，实施灵活的质量门系统的可能性区分DVCS和CVCS。 您也可以在这个级别解决您的权限问题。 只有less数人可以进入主回购。 对于层次的每个级别，有相应的访问策略单独的回购。 事实上，这种方法在团队层面上可以非常灵活。 你应该让每个团队决定是否要在他们之间分享他们的团队回购，或者如果他们想要一个更具层次的方法，只有团队领导可以承诺团队回购。
（这张照片是从Joel Spolsky的hginit.com偷来的）
在这一点上还有一点要说：尽pipeDVCS提供了很好的合并能力，但这永远不能取代使用持续集成。 即使在那个时候，你也有很大的灵活性：主干回购CI，团队回购CI，问答回购等。
Git在企业环境中：
就像你已经指出的那样，Git可能不是企业环境的理想解决scheme。 重复你的一些担心，我觉得最值得注意的是他们：
-
在Windows上仍然有些不成熟的支持（请改正，如果最近改变了）现在Windows有github的Windows客户端 ， tortoisegit ， SourceTree从atlassian - 缺乏成熟的GUI工具，没有一stream的公民vdiff / merge工具集成
- 在其内部工作之上的界面与抽象程度非常低的界面不一致
- svn用户的学习曲线非常陡峭
- Git是非常强大的，可以很容易地修改历史logging，如果你不知道自己在做什么，就会非常危险（有时你甚至会认为自己知道）
- 没有可用的商业支持选项
我不想在这里启动git vs. hg flamewar，您已经通过切换到DVCS来完成正确的步骤。 Mercurial解决了上面的一些问题，因此我认为它更适合于企业环境：
- 所有运行python的平台都被支持
- 在所有主要平台（win / linux / OS X），头等的合并/ vdiff工具集成上都有很棒的GUI工具
- 非常一致的界面，为svn用户轻松过渡
- git也可以做大部分的事情，但是提供了一个更清晰的抽象。 危险的行动总是明确的。 高级function通过必须明确启用的扩展来提供。
- 商业支持来自于亚selenium酸盐。
总之，在企业中使用DVCS时，我认为select一种引入最less摩擦的工具是很重要的。 为了成功转型，考虑开发者之间的不同技能（关于VCS）尤为重要。
减less摩擦：
好吧，因为你似乎真的陷入困境，有两个select离开恕我直言。 没有工具可以让git变得更简单。 混帐是复杂的。 要么你面对这个问题，要么围绕着git：
- 获得整个团队的git入门课程。 这应该只包括基础和一些练习（重要！）。
- 将master repo转换为svn，让“young-stars” git-svn 。 这给大多数开发人员提供了一个易于使用的界面，并且可以弥补团队中缺乏的纪律，而年轻的明星可以继续使用git来做自己的回购。
说实话，我认为你真的有一个人的问题，而不是一个工具问题。 可以做些什么来改善这种情况？
- 你应该清楚地表明，你认为你的当前进程将以一个可维护的代码库结束。
- 投入一些时间进入持续集成。 如上所述，无论您使用哪种VCS，都无法取代CI。 你说有人把垃圾推到主回购：让他们修理垃圾，而红色的警报熄灭，并指责他们打破build设（或不符合质量指标或任何其他）。
我是一个合理规模的开发组织的SCM工程师，在过去一年左右我们从svn转换到git。 我们以集中的方式使用它。
我们使用gitosis来托pipe存储库。 因为git的分支单元基本上就是存储库，所以我们将单一的svn版本库分成许多小的git版本库。 （有办法可以解决这个问题，但是它们很笨拙。）如果你想要每个分支的访问控制， gitolite可能是一个更好的方法。 如果你想花钱的话，还有一个GitHub的防火墙版本。 就我们的目的而言，gitosis是好的，因为我们的存储库拥有相当开放的权限。 （我们有许多可以访问存储库组的人员，每个人都可以读取所有存储库）。我们使用gitweb作为web界面。
至于你的一些具体问题：
- 合并：您可以使用您select的可视化合并工具; 在各个地方有关于如何设置的说明。 在我看来，你可以在你的本地回购中完成合并并检查其有效性这一事实是git的一大优点。 您可以在推送任何内容之前validation合并。
- graphics用户界面：我们有几个人在使用TortoiseGit，但我并不真正推荐它。 它似乎以奇怪的方式与命令行进行交互。 我必须同意这是一个需要改进的领域。 （也就是说，我不是一般版本控制GUI的粉丝。）
- 小组跟踪分支：如果您使用提供更细粒度ACL（如gitolite）的东西，可以很容易地做到这一点，但您也可以通过连接各种开发人员的本地存储库来创build共享分支 – 一个git仓库可以有多个远程仓库。
我们转而使用git，因为我们有很多远程开发人员，而且因为我们在Subversion方面有很多问题。 我们仍然在尝试工作stream程，但是现在我们基本上像使用Subversion一样使用它了。 另一件我们喜欢的事情是，它开辟了其他可能的工作stream程，比如使用分级存储库进行代码审查和小组间的代码共享。 这也鼓励很多人开始跟踪他们的个人脚本等等，因为创build一个存储库非常容易。
是的，我知道，Linus从来没有打算这样做。
实际上，Linus认为中央系统是行不通的。
而且， 独裁者和中尉的工作stream程有什么问题呢？
请记住，git是一个分布式系统; 不要试图把它当作中央使用。
（更新）
如果你不尝试使用git，那么你的大部分问题都会消失，因为它是“svn on steroids”（因为不是）。
而不是使用裸仓库作为中央服务器，每个人都可以推送（可能会搞砸），build立一些处理合并的集成pipe理器，这样只有他们可以推送到裸仓库。
通常这些人应该是团队的领导者：每个领导者都将他自己的团队的工作整合起来，并将其推向有福的仓库。
更好的是，别人（也就是独裁者）从团队领导中拉出来，把他们的改变整合到有福的仓库中。
这个工作stream程没有任何问题，但我们是一个过度劳累的创业公司，需要我们的工具来替代人们的时间和注意力。 没有人有带宽甚至做代码审查，更不用说是仁慈的独裁者。
如果集成商没有时间审查代码，那很好，但是你仍然需要有人来整合每个人的合并。
做混帐并不需要太多的时间。
git pull A git pull B git pull C
git 确实代替了人类的时间和注意力; 这就是为什么它是写在第一位。
- GUI工具还不成熟
gui工具可以很好地处理基本的东西。
高级操作需要一个编码器/书呆子的心态（例如，我很舒服地从命令行工作）。 掌握概念需要一点时间，但并不难。
- 使用命令行工具，很容易搞砸一个合并，并消除别人的变化
除非你有许多无能的开发者完全写入“中央仓库”，否则这不会成为问题。
但是，如果您设置了工作stream程以便只有less数人（集成人员）写入“有福”的存储库，那就不成问题了。
Git并不容易搞砸合并。
当存在合并冲突时，git会清楚地标出冲突的行，以便知道哪些更改是您的，哪些不是。
用svn或其他任何工具（non-dsitributed）来清除别人的代码也很容易。 事实上，使用这些其他工具会更容易，因为您往往会“长期处于变化之中”，并且在某些时候合并会变得非常困难。
而且由于这些工具不知道如何合并，所以最终总是需要手动合并。 例如，只要有人提交到您正在编辑的文件，就会将其标记为需要手动parsing的冲突; 现在这是一个维修噩梦。
使用git，大多数情况下不会有任何合并冲突，因为git实际上可以合并。 在发生冲突的情况下，git会清楚地标出你的行，这样你就可以确切地知道你的变化是什么，哪些变化是来自其他人。
如果有人在解决合并冲突的同时抹杀了他人的变化，那么不会是错误的：要么是因为解决冲突是必要的，要么是因为他们不知道自己在做什么。
它不提供超出全局只读或读写权限的每用户存储库权限
如果您有权限访问存储库的任何部分，则可以对存储库的每个部分执行同样的操作，因此您无法在中央服务器上创build小组跟踪分支，而其他人无法做到这一点乱七八糟的。
- “任何事情都行”或“仁慈的独裁者”以外的工作stream很难鼓励，更不用说强制执行了
当你停止尝试使用Git，就好像它是一个集中式系统一样，这些问题就会消失。
- 目前尚不清楚是否最好使用一个单一的大型资源库（可以让所有人都搞砸），或者是每个组件库有很多（这使得头版试图同步版本）。
判决电话。
你有什么样的项目？
例如：项目A的版本xy是否依赖于项目B的版本wz，以便每次检查项目A的xy时，还必须检出项目B的wz，否则不会生成？ 如果是的话，我会把项目A和项目B放在同一个仓库中，因为它们显然是一个项目的两个部分。
这里最好的做法是用你的大脑
- 有了多个版本库，也不清楚如何从中央库复制别人所有的源代码，或者在昨天下午4点半之前完成所有的工作。
我不确定你是什么意思。
我强烈build议http://code.google.com/p/gerrit/用于企业工作。; 它为您提供访问控制和内置的基于评论的工作stream程。 它针对任何LDAP系统进行身份validation。 你可以通过http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin把它与Hudson连接起来，让你在正在审查的时候构build和testing变化。; 这是一个令人印象深刻的设置。
如果你决定使用gerrit，我build议尽量保持一个非常线性的历史，而不是像一些开源的人喜欢的分支的历史。 格里特把这句话称为“只允许快进变化”。 那么你可以使用更多的分支和合并方式，对于发行版和其他东西。
基于我在2010年通过Git的大型电信公司的开发经理，我正在回答这个问题
你在这里遇到了一系列不同的问题：
- 工作stream程
- 客户端工具
- 服务器访问控制和集成
工作stream程
我们成功地采用了中央资料库模式：我们在企业项目（500万用户群的大型门户网站）中拥有的是事实上的中央资料库，生成正式版本，然后通过交付过程（在我们案例，由三个层次的testing和两个部署组成）。 每个开发人员pipe理他自己的回购，我们在每个function分支的基础上工作。
客户端工具
现在有几个选项可用，这是一个非常拥挤的地区。 许多开发人员都使用Git插件成功地使用了IntelliJ Idea和Eclipse ，没有任何其他的东西。 另外大部分Linux开发人员都使用CLI git客户端，没有任何问题。 一些Mac开发人员正在成功使用Tower Git 。 请注意， 这些客户端都不能阻止用户与中央存储库“搞砸”：需要服务器端控制机制
服务器访问控制和集成
如果你想避免开发人员“搞砸”你的Git仓库，你需要select一个解决scheme：
- 揭示了一个体面的networkingpipe理界面来做每一个操作
- 允许您强制执行用户身份（使用“裸”Git存储库非常容易代表其他人）
- 为您提供细粒度的安全性（例如，您可以防止FORCE-PUSH，并为某些开发人员/组设置某些分支）
- 与您的公司authentication系统（即LDAP，Windows ActiveDirectory）
- 为您提供全面的审计（SOX合规性对于大型企业有时非常重要）
有没有这么多的即时可用的服务器端解决scheme，可以帮助这个，我build议你看看其中的一个：
- Gitorious ：它可以提供基本的访问级安全性，但是它缺less精细的权限控制，因此您可能需要编写一些代码来处理分支级别权限等情况。 它也缺乏与现有企业authentication机制的整合
- GitHub Enterprise：最近由GitHub发布，它在您的公司中使用了GitHub。 它缺乏SOX兼容性和细粒度的安全性
- Gerrit ：它可以提供良好的访问级安全性并与企业authentication系统集成，但缺lessSOX合规性和SSO。 另外一些操作只能通过CLI通过SSH完成
- GitEnterprise ：它提供分支级别权限，SSO，SOX合规性，完整的基于Web的pipe理。 它最近也与Gerrit集成，所以它也为您提供了一个完整的Gerrit实例
希望这可以帮助！
在这些工具上 ，MacOS-X用户发现GitX（http://gitx.frim.nl/）非常简单而有效。; 缺点是不支持Git客户端钩子（在$ GIT_ROOT / .git /钩子下）。
总的来说，我强烈地select了一个支持以下方面的细粒度访问控制的工具： – 分支机构（为了将稳定版本分支从主题分支中分离出来，需要更多的灵活性和灵活性） – 身份执行（作者/提交者）。 这是SOX的关键 – git命令限制 – audit-trail。 这是SOX的关键
我已经成功地使用这些function的是：
- Gerrit代码审查（http://code.google.com/p/gerrit/）;
- GitEnterprise（http://gitenterprise.com）;
- CollabNet TeamForge（http://www.collab.net/gotgit）在幕后使用了Gerrit 2.1.8
PS 不要低估SOX和CMMI合规性 ：很多时候，您的公司企业安全策略决定了多lessselect。
希望这可以帮助。
卢卡。
我们最近从svn切换到git。 因为git-daemon不能用于msysgit，所以我们select了一个使用gitosis的Linux服务器上的中央存储库方法。
为了消除把主人搞砸的可能性，我们简单地将其删除。 相反，我们通过合并select用于testing的分支并标记合并来准备所有版本。 如果它通过testing，提交将被标记为一个版本并投入生产。
为了处理这个问题，我们有一个发布pipe理器的angular色。 发布经理负责在每个分支准备好testing之前对其进行评估。 然后，当产品拥有者决定是时候将批准的分支捆绑在一起以用于新的testing版本时，发布pipe理器执行合并。
我们也有第二级服务台的轮换angular色，至less对我们来说，工作量是可以同时兼顾两个angular色的。
作为没有主人的好处，不可能在没有通过发布pipe理器的情况下将任何代码添加到项目中，所以我们直接发现了之前默默添加到项目中的多less代码。
审查过程开始于分支机构将差异提交给评审板，并在“审查”下的分支名称（我们有一个基于看板的工作stream）的白板上贴上绿色的贴子，或者如果它是已完成用户的一部分把整个故事卡移动到“审查”，然后把邮件放在那里。 发卡经理是将卡片移到“准备testing”的人，然后产品所有者可以select在下一个testing版本中join哪些卡片。
在进行合并时，发布pipe理器还确保合并提交具有合理的提交消息，可以在产品所有者的更改日志中使用该提交消息。
当一个版本被投入生产时，标签被用作分支的新基础，所有现有的分支都被合并。 这样所有的分支都有一个共同的父母，这使得更容易处理合并。
这听起来像你的问题是，你还没有决定或build立一个工作stream程。 Git足够灵活，可以像SVN或任何其他VCS一样使用它，但是它非常强大，如果你没有build立每个人都必须遵循的规则，那么你只会一团糟。 我会推荐上面提到的独裁者 – 中尉工作stream程，但是结合Vincent Driessen描述的分支模型。 欲了解更多信息，请参阅David Bock的这些截屏video，以及Mark Derricutt撰写的这一截屏video。
我会join一个“你有没有考虑过”的post。
Bazaar的一大优点就是它的灵活性。 这是它击败所有其他分布式系统的地方。 您可以以集中模式，分布式模式运行Bazaar，或者得到这个：这两个（意味着开发人员可以select适合他们的工作组或最适合他们工作组的模型）。 您也可以在路途中断开集中式存储库，并在返回时重新连接。
最重要的是，优秀的文档和一些能够让你的企业感到高兴的东西：可用的商业支持。
- 安装像Github FI一样体面的networking界面
- 坚持一个相对集中的模式（最初）来保持人们的舒适。
- 为每个共享分支运行一个持续集成构build。
- 分享一套好的全球gitconfiguration选项。
- 把git整合到你的shell中，用bash完成，并提示当前分支。
- 尝试IntelliJ的Git集成作为合并工具。
- 确保你.gitignore适当。
关于第3和第4点（每用户，每节，每分支权限），请看gitolite （在Pro Git书籍中涵盖： http : //progit.org/book/ch4-8.html ）。
政治与否，Git是任何DCVS的好select。 就像任何强大的工具一样，值得花一点时间来理解工具的devise工作方式，为此，我强烈推荐Pro Git书籍。 花了几个小时，从长远来看可以节省很多的挫折。
GUI：目前，TortoiseGit v1.7.6应该可以适用于大多数日常操作。 日志，提交，推，拉，取，比较，合并，分支机构，樱桃采摘，重build，标记，出口，藏匿，添加子模块等…本地也支持x64
为了在有很多开发人员的开发团队中高效地使用git，需要一个持续build立和testing的CI系统。 jenkins提供这样一种车辆，我强烈build议。 无论做什么，整合件都要做，而且更经常地做得更便宜。
更适合于合作开发比gitosis或gitolite，但开源是Gitorious 。 这是一个Ruby on Rails应用程序，用于处理存储库和合并的pipe理。 它应该解决你的许多问题。
Git允许创build私人分支。 这鼓励开发人员经常犯下错误，以便将修改分解为小的提交。 当开发人员准备发布他的更改时，他会推送到中央服务器。 如果需要的话，他可以使用预先提交的脚本来validation他的代码。
恩智浦通过一个通用平台（企业规模）pipe理Git和Subversion，将Android移动开发与传统软件项目整合在一起： http ： //www.youtube.com/watch？v = QX5wn0igv7Q
