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

我把 git 用于个人项目，觉得它很棒。它快速、灵活、强大，而且适用于远程开发。

但是现在工作上强制执行，坦白说，我们遇到了问题。

开箱即用，Git 似乎不适合在一个大型(20多个开发人员)组织中进行集中开发，开发人员的能力和 Git 复杂程度各不相同——特别是与针对这种环境的其他源代码控制系统(如 Perforce 或 Subversion)相比。(是的，我知道，莱纳斯从来没有这个打算。)

But - for political reasons - we're stuck with git, even if it sucks for what we're trying to do with it.

以下是我们看到的一些情况:

  • GUI 工具还不成熟
  • Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes
  • 除了全局只读或读写权限之外，它不提供每个用户的存储库权限
  • 如果您对存储库的任何部分有权限，那么您可以对存储库的任何部分执行相同的操作，这样您就不能在中央服务器上创建一个其他人无法干扰的小组跟踪分支。
  • 除了“随心所欲”或“仁慈的独裁者”之外，很难鼓励工作流，更不用说强制执行了
  • It's not clear whether it's better to use a single big repository (which lets everybody mess with everything) or lots of per-component repositories (which make for headaches trying to synchronize versions).
  • 对于多个存储库，我们也不清楚如何通过从中央存储库中提取来复制其他人拥有的所有源，或者从昨天下午4:30开始获取所有内容。

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

如果你正处于这种情况——或者你通常有一些工具、技巧和窍门，可以让你在一个大型组织中更容易、更高效地使用 git，因为有些人不喜欢使用命令行——我很想听听你的建议。

顺便说一句，我已经在 LinkedIn 上提出了这个问题的一个版本，但是没有得到真正的答案，只有很多人说: “天哪，我也想知道!”

UPDATE: Let me clarify...

在我工作的地方，除了 git ，我们不能使用其他任何东西。这不是一个选择。我们被困住了。我们不能使用 mercurial，svn，bitkeep，Visual Source Safe，ClearCase，PVCS，SCCS，RCS，bazaar，Darcs，montone，Perforce，Foss，AccuRev，CVS，甚至我在1987年使用过的苹果好的 ol’Projector。所以，欢迎你讨论其他选择，如果你不讨论 git，你就不会得到赏金。

还有，我在找 practical tips on how to use git in the enterprise。我把一大堆问题列在了这个问题的首位。同样，欢迎人们讨论理论，但 如果你想赚赏金，给我解决办法。

19507 次浏览
小开

是的，我知道，莱纳斯不是故意的。

实际上，莱纳斯认为集中式系统根本无法工作。

And, what's wrong with the 独裁者和副手的工作流程？

diagram

记住，git 是一个 分发系统; 不要试图将它作为一个中心系统来使用。

(更新)

Most of your problems will go away if you don't try to use git as if it was "svn on steroids" (because it's not).

Instead of using a bare repository as a central server where everyone can push to (and potentially screw up), setup a few integration managers that handle merges, so that only they can push to the bare repository.

通常，这些人应该是团队的领导者: 每个领导者整合自己团队的工作，并将其推送到受保护的存储库中。

更好的是，其他人(例如独裁者)从团队领导者那里抽调人员，并将他们的更改集成到受保护的存储库中。

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

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

做饭后拉手术不需要那么多时间。

git pull A
git pull B
git pull C

git 是的 substitute for human time and attention; that's why it was written in the first place.

  • GUI 工具还不成熟

GUI 工具可以很好地处理基本的东西。

高级操作需要一种编码员/书呆子的心态(例如，我喜欢在命令行上工作)。理解这些概念需要一些时间，但这并不难。

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

除非有许多不称职的开发人员能够对“中央存储库”进行完全的写访问，否则这不会是一个问题。

但是，如果您设置您的工作流程，以便只有少数人(集成商)向“受保护的”存储库写代码，那就不会有问题。

Git 不容易搞砸合并。

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

It's also easy to obliterate other people's code with svn or any other (non-dsitributed) tool. In fact, it's way easier with these other tools because you tend to "sit on changes" for a long time and at some point the merges can get horribly difficult.

而且因为这些工具不知道如何合并，所以最后总是不得不手动合并。例如，一旦有人提交了您正在本地编辑的文件，它将被标记为需要手动解决的冲突; 现在 那个是一个维护噩梦。

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

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

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

  • 如果您对存储库的任何部分有权限，那么您可以对存储库的任何部分执行相同的操作，这样您就不能在中央服务器上创建一个其他人无法干扰的小组跟踪分支。

  • 除了“随心所欲”或“仁慈的独裁者”之外，很难鼓励工作流，更不用说强制执行了

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

  • 目前还不清楚是使用一个单一的大型存储库(它让每个人都可以搞乱所有东西)好，还是使用大量的每个组件的存储库(这使得同步版本变得非常麻烦)好。

Judgment call.

你有什么项目？

例如: 项目 A 的 x.y 版本是否依赖于项目 B 的具体版本 w.z，这样 每次都是你检查项目 A 的 x.y，你也必须检查项目 B 的 w.z，否则它不会构建？如果是这样，我会将项目 A 和项目 B 放在同一个存储库中，因为它们显然是单个项目的两个部分。

这里的最佳实践是到 动动脑子

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

我不明白你的意思。

小开

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

我们使用 Gitosis托管存储库。我们将单片 svn 存储库分解成许多更小的 git 存储库，因为 git 的分支单元基本上就是存储库。(有很多方法可以避免这种情况，但都很尴尬。)如果需要每个分支类型的访问控制，gitolite可能是一种更好的方法。如果你愿意花钱，还有一个 GitHub的内部防火墙版本。对于我们的目的，gitosis 很好，因为我们对存储库有相当开放的权限。(我们有一组人，他们可以对存储库组进行写访问，每个人都可以对所有存储库进行读访问。)我们使用 gitweb 作为网页界面。

至于你的一些具体担忧:

  • Merge: 您可以使用自己选择的可视化合并工具; 在不同的地方有关于如何设置它的说明。事实上，您可以在本地回购中完全进行合并并检查其有效性，在我看来，这是 git 的一个主要优点; 您可以在推动任何操作之前验证合并。
  • 图形用户界面: 我们有一些人使用 TortoiseGit，但我并不推荐使用它; 它似乎以奇怪的方式与命令行交互。我必须承认，这是一个需要改进的领域。(也就是说，我一般不喜欢用 GUI 进行版本控制。)
  • 小组跟踪分支: 如果你使用像 gitolite 这样提供更细粒度 ACL 的东西，那么做到这一点很容易，但是你也可以通过连接各种开发者的本地存储库来创建一个共享分支ーー一个 git repo 可以有多个远程。

我们转向 git 是因为我们有很多远程开发人员，而且 Subversion 有很多问题。我们仍在尝试使用工作流，但目前我们基本上使用的方式与使用 Subversion 的方式相同。我们喜欢它的另一点是，它开放了其他可能的工作流，比如使用临时存储库进行代码审查，以及在小组之间共享代码。它还鼓励很多人开始跟踪他们的个人脚本等等，因为创建一个存储库非常容易。

小开

更适合于协作开发，而不是关塔那摩或沸石，但开放源码是 Gitorious。它是一个 RubyonRails 应用程序，用于处理存储库管理和合并。应该能解决你的很多问题。

小开
最佳答案

与普遍观点相反，我认为在企业环境中使用 DVCS 是一个理想的选择，因为它支持非常灵活的工作流。我将首先讨论 DVCS 与 CVCS 的使用，最佳实践，然后特别讨论 git。

企业环境下的 DVCS 与 CVCS:

我不想在这里谈论一般的利弊，而是把重点放在你的上下文上。使用 DVCS 需要比使用集中式系统更有纪律的团队，这是一个常见的概念。这是因为集中式系统为您提供了一个简单的方法来 执行您的工作流程，使用一个分散式系统需要 更多的交流和纪律来坚持建立的约定。虽然这可能看起来会产生开销，但我认为增加交流对于使其成为一个好的过程是有好处的。您的团队将需要就代码、更改和项目状态进行一般性的交流。

学科背景下的另一个维度是鼓励分支和实验。这里引用了 Martin Fowler 最近的 Bliki 条目 版本控制工具中的一句话，他发现了对这种现象的一个非常简洁的描述。

DVCS 鼓励快速分支 实验。你可以做分支 在颠覆中，但事实上他们 are visible to all discourages people 为... ... 开设分行 类似于 DVCS 鼓励检查点的工作: 提交不完整的更改，则 甚至不能编译或通过测试 你当地的仓库。再一次，你可以 在开发人员分支上执行此操作 Subversion, but the fact that such 分支在共享空间中 人们不太可能这么做。

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

工作流程:

Larry Osterman (Windows 团队中的一名微软开发人员)有一份关于他们在 Windows 团队中使用的工作流程的 很棒的博客文章。最值得注意的是:

  • 一个干净，高质量的代码只主干(主回购)
  • 所有的开发都发生在特性分支上
  • 特写组有团队回购
  • 他们会定期将最新的主干更改合并到他们的特性分支(前向积分)中
  • 完整的特性必须通过几道质量关卡，例如评审、测试覆盖率、问答(自行回购)
  • 如果一个功能已经完成并且具有可接受的质量，它将被合并到主干(Reverse Integrate)中

正如您所看到的，让每个存储库独立运行，您可以将不同的团队以不同的速度进行分离。此外，实现灵活的质量门系统的可能性区分了 DVCS 和 CVCS。您也可以在这个级别解决您的权限问题。只有少数人应该被允许进入主回购。对于层次结构的每个级别，都有一个单独的回购协议和相应的访问策略。实际上，这种方法在团队层面上可以非常灵活。你应该让每个团队自己决定他们是否想在他们之间共享他们的团队回购，或者他们是否想要一个只有团队领导可以承诺团队回购的更层次化的方法。

Hierachical Repositories

(The picture is stolen from Joel Spolsky's Hginit.com.)

One thing remains to be said at this point though:- even though DVCS provides great merging capabilities, this is 永远不会 a replacement for using Continuous Integration. Even at that point you have a great deal of flexibility: CI for the trunk repo, CI for team repos, Q&A repos etc.

企业环境下的 Git:

正如您已经指出的，Git 可能不是企业上下文的理想解决方案。重复一下你的一些担忧，我认为最值得注意的是:

  • 对 Windows 的支持还有些不成熟(如果最近有变化请纠正我) 现在 Windows 已经有了 Github 窗口客户端，乌龟，来自 atlassian 的 SourceTree
  • 缺乏成熟的 GUI 工具，没有一流的公民 vdiff/merge 工具集成
  • 不一致的接口，在其内部工作之上有一个非常低层次的抽象
  • Svn 用户的学习曲线非常陡峭
  • Git is very powerful and makes it 放松 to modify history, very dangerous if you don't know what you are doing (and you will sometimes even if you thought you knew)
  • 没有可用的商业支持选项

我不想在这里开始一场 git 与 hg 之战，通过切换到 DVCS，您已经完成了正确的步骤。Mercurial 解决了上面的一些问题，因此我认为它更适合于企业环境:

  • 支持所有运行 python 的平台
  • 所有主流平台(win/linux/OS X)上都有出色的 GUI 工具，一流的合并/vdiff 工具集成
  • 非常一致的界面，易于转换为 svn 用户
  • 可以做 git 能做的大部分事情，但是提供了一个更清晰的抽象。危险行动总是明确的。高级特性是通过必须显式启用的扩展提供的。
  • Commercial support is available from selenic.

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

减少摩擦:

好吧，因为你似乎真的被困在这种情况下，有两个选择左恕我直言。 没有工具可以让 git 变得不那么复杂; git 是很复杂

  1. Get a git introductory course for the whole team. This should include the basics only and some exercises (important!).
  2. 将主回购转换为 svn，并让“年轻明星”Git-svn。这给大多数开发人员提供了一个易于使用的界面，并且可以弥补你的团队缺乏纪律性的不足，而那些年轻的明星可以继续使用 git 进行他们自己的回购。

说实话，我觉得你真的有人际关系的问题而不是工具的问题。可以做些什么来改善这种情况？

  • You should make it clear that you think your current process will end up with a maintainable codebase.
  • Invest some time into Continous Integration. As I outlined above, regardless which kind of VCS you use, there's never a replacement for CI. You stated that there are people who push crap into the master repo: Have them fix their crap while a red alert goes off and blames them for breaking the build (or not meeting a quality metric or whatever).
小开

我还会加上一个“你有没有考虑过”的帖子。

Bazaar 最大的优点之一就是它的灵活性。这就是它打败所有其他分布式系统的地方。您可以在集中模式、分布式模式下操作 Bazaar，或者两者兼而有之(这意味着开发人员可以选择他们喜欢的模式，或者哪种模式最适合他们的工作组)。您还可以在路上断开中央存储库的连接，并在返回时重新连接它。

最重要的是，优秀的文档和一些可以让您的企业满意的东西: 可用的商业支持。

小开
  • Install a decent web interface, like Github FI
  • 坚持相对集中的模式(最初) ，让人们感到舒适。
  • 为 每个共享分支运行持续集成构建。
  • 共享一组好的全局 git 配置选项。
  • 将 git 集成到您的 shell 中，使用 bash 完成，并使用当前分支提示符。
  • Try IntelliJ's Git Integration as a merge tool.
  • 确保你，适当地拒绝。
小开

关于第3点和第4点(每个用户、每个部分、每个分支的权限) ，看看 Gitolite(在 Pro Git 的书中有介绍: http://progit.org/book/ch4-8.html)。

不管政治与否，Git 都是 DCVS 的一个很好的选择。像任何强大的工具一样，值得花一点时间来了解这个工具是如何设计来工作的，为此，我强烈推荐 Pro Git 的书。从长远来看，花几个小时在这上面可以避免很多挫折。

小开

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

为了消除搞砸主人的可能性，我们只是删除了它。相反，我们通过合并选择用于测试的分支并标记合并来准备所有发布。如果它通过了测试，提交就会被标记为版本并投入生产。

为了处理这个问题，我们有一个发布管理器的轮换角色。发布管理员负责在每个分支准备好进行测试之前对其进行审查。然后，当产品所有者决定是时候将经过批准的分支捆绑在一起，用于新的测试版本时，发布管理器执行合并。

我们还有一个二级服务台的轮换角色，至少对我们来说，工作量是这样的，这是可能有两个角色在同一时间。

没有主人的好处是不可能在没有通过发布管理器的情况下向项目添加任何代码，所以我们直接发现之前默默地向项目添加了多少代码。

审查过程开始于分支机构的所有者提交 diff 到审查板，并在白板上放置一个绿色的发表它，上面写着分支名称(我们有一个基于看板的工作流程)“ for review”，或者如果它是一个已完成的用户故事的一部分，将整个故事卡移到“ for review”，然后把帖子放在上面。发布管理器是一个移动卡片和便利贴到“准备测试”的人，然后产品所有者可以选择在下一个测试发布中加入哪些卡片。

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

When a release has been put in production the tag is used as the new base for branches and all existing branches are merged with it. This way all branches has a common parent which makes it easier to handle merges.

小开

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

如果您决定使用 gerrit，我建议尝试保持一个非常线性的历史，而不是像一些开源人员所喜欢的那样保持一个分支历史。Gerrit 将此解释为“仅允许快进更改”然后，您可以像以前一样更多地使用分支和合并，用于发布等等。

小开

It sounds like your problem is that you haven't decided on or instituted a workflow. Git is flexible enough to use it like svn or any other VCS, but it's so powerful that if you don't establish rules that everybody must follow then you're just gonna end up with a mess. I would recommend the dictator-lieutenant workflow that somebody mentioned above, but combined with the branching model described by 文森特 · 德里森. For more info see these screencasts 作者: David Bock, and this one by Mark Derricutt.

小开

图形用户界面: 目前，TortoiseGit v1.7.6对于大多数日常操作应该没有问题。 日志、提交、推、拉、获取、差异、合并、分支、初选、基础、标记、导出、隐藏、添加子模块等。 本机也支持 x64

小开

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

小开

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

你在这里有一系列完全不同的问题:

  • 工作流
  • 客户工具
  • server access control and integration

工作流

We successfully adopted a central repository mode: what we have in our enterprise project (a large portal for a 5 million user base) is a de-facto central repository that produces the official builds then are taken trough the delivery process (which, in our case, is composed of three level of testing and two deployments). Every developer manages his own repo, and we work on a branch-per-feature basis.

客户工具

There are now several options available, this is now a very crowded area. Many developers are successfully using 智慧的想法 and 使用 Git 插件的 Eclipse, without any other stuff. Also most of the Linux developers are using CLI git client, without any problem. Some Mac developers are successfully using 高塔饭桶. Please note that 这些客户都不是 can prevent the user to "mess up" with the central repository: a server side control mechamism is needed

服务器访问控制和集成

如果您想避免开发人员“搞乱”您的 Git 存储库，那么您确实需要选择以下解决方案:

  • 公开一个体面的网络管理界面，做每一个操作
  • 允许您强制执行用户标识(使用“裸”Git 存储库非常容易代表其他人提交)
  • 为您提供细粒度的安全性(例如，您可以防止 FORCE-PUSH 并设置一些分支，以便某些开发人员/组只读)
  • 与您的企业认证系统(即 LDAP、 WindowsActiveDirectory)集成
  • 为您提供完整的审计(SOX 遵从性有时对于大公司非常重要)

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

  • Gitorious : 它可以提供基本的访问级别安全性，但是缺乏开箱即用的细粒度权限控制，因此您可能需要进行一些编码来处理诸如分支级别权限之类的场景。它还缺乏与现有公司认证机制的集成
  • GitHub 企业版: 最近由 GitHub 发布，它在您的企业中具有 GitHub 特性，缺乏 SOX 遵从性和细粒度安全性
  • Gerrit : 它可以提供良好的访问级别安全性和与企业认证系统的集成，但缺乏 SOX 遵从性和 SSO。还有一些操作只能通过 SSH 通过 CLI 完成
  • GitEnterprise : 它提供分支级权限、 SSO、 SOX 遵从性、完全基于 Web 的管理。它最近还与 Gerrit 集成了，因此它还为您提供了一个完整的 Gerrit 实例

希望这个能帮上忙！

小开

在 tools上，MacOS-X 用户发现 gitX ( http://GitX.frim.nl/)非常简单有效。缺点是不支持 GIT Client 挂钩($GIT _ ROOT/下的挂钩)。Git/Hook).

总的来说，我强烈地选择了一个支持 细粒度访问控制细粒度访问控制的工具: - 分支(为了将具有严格安全性的稳定版本分支与主题-需要更多灵活性和灵活性的分支隔离开来) - 身份执行(作者/提交者) 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

不要低估 SOX 和 CMMI 遵从性: 很多时候，您的选择是有限的，这取决于您的公司企业安全政策。

Hope this helps.

卢卡。

小开

为了在拥有大量开发人员的开发团队中有效地使用 git，需要一个持续构建和测试的 CI 系统。詹金斯提供了这样一种交通工具，我强烈推荐。集成部分必须无论如何都要完成，而且更早和更频繁地完成这项工作要便宜得多。

小开

NXP 通过一个公共平台(在企业级)管理 Git 和 Subversion，将 Android 移动开发与传统软件项目 http://www.youtube.com/watch?v=QX5wn0igv7Q集成在一起


提交答案