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

Git-Based Source Control in the Enterprise: Suggested Tools and Practices?

提问by Bob Murphy

I use git for personal projects and think it's great. It's fast, flexible, powerful, and works great for remote development.

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

But now it's mandated at work and, frankly, we're having problems.

但现在它在工作中被强制执行，坦率地说，我们遇到了问题。

Out of the box, git doesn't seem to work well for centralized development in a large (20+ developer) organization with developers of varying abilities and levels of git sophistication - especially compared with other source-control systems like Perforce or Subversion, which are aimed at that kind of environment. (Yes, I know, Linus never intended it for that.)

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

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

但是——出于原因——我们被 git 困住了，即使它对我们试图用它做的事情来说很糟糕。

Here are some of the things we're seeing:

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

• The GUI tools aren't mature
• Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes
• It doesn't offer per-user repository permissions beyond global read-only or read-write privileges
• If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.
• Workflows other than "anything goes" or "benevolent dictator" are hard to encourage, let alone enforce
• 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).
• With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.

• GUI工具不成熟
• 使用命令行工具，很容易搞砸合并并消除其他人的更改
• 除了全局只读或读写权限之外，它不提供每个用户的存储库权限
• 如果您对存储库的任何部分都有权限，则可以对存储库的每个部分执行相同的操作，因此您无法执行其他人无法在中央服务器上创建小组跟踪分支之类的操作惹。
• 除了“一切顺利”或“仁慈的独裁者”之外的工作流程都很难鼓励，更不用说强制执行了
• 目前尚不清楚使用单个大存储库（这让每个人都把所有东西都弄乱）还是使用大量每个组件的存储库（这会导致尝试同步版本的麻烦）更好。
• 对于多个存储库，也不清楚如何通过从中央存储库中提取来复制其他人拥有的所有源，或者执行诸如获取昨天下午 4:30 之前的所有内容之类的操作。

However, I've heard that people are using git successfully in large development organizations.

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

If you're in that situation - or if you generally have tools, tips and tricks for making it easier and more productive to use git in a large organization where some folks are not command line fans - I'd love to hear what you have to suggest.

如果您处于这种情况 - 或者如果您通常拥有工具、技巧和窍门，可以在一些人不喜欢命令行的大型组织中更轻松、更高效地使用 git - 我很想听听您的意见建议。

BTW, I've asked a version of this question already on LinkedIn, and got no real answers but lots of "gosh, I'd love to know that too!"

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

UPDATE: Let me clarify...

更新：让我澄清...

Where I work, we can't use ANYTHING other than git. It's not an option. We're stuck with it. We can't use mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, or even Apple's good ol' Projector that I used in 1987. So while you're welcome to discuss other options, you ain't gonna get the bounty if you don't discuss git.

在我工作的地方，我们不能使用 git 以外的任何东西。这不是一个选择。我们被它困住了。我们不能使用 mercurial、svn、bitkeeper、Visual Source Safe、ClearCase、PVCS、SCCS、RCS、bazaar、Darcs、monotone、Perforce、Fossil、AccuRev、CVS，甚至我在 1987 年使用的 Apple 的好投影仪。因此，虽然欢迎您讨论其他选项，但如果您不讨论 git，您将无法获得奖励。

Also, I'm looking for practical tips on how to use git in the enterprise. I put a whole laundry list of problems we're having at the top of this question. Again, people are welcome to discuss theory, but if you want to earn the bounty, give me solutions.

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

采纳答案by Johannes Rudolph

Against the common opinion, I think that using a DVCS is an ideal choice in an enterprise setting because it enables very flexible workflows. I will talk about using a DVCS vs. CVCS first, best-practices and then about git in particular.

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

DVCS vs. CVCS in an enterprise context:

企业环境中的 DVCS 与 CVCS：

I wont talk about the general pros/cons here, but rather focus on your context. It is the common conception, that using a DVCS requires a more disciplined team than using a centralized system. This is because a centralized system provides you with an easy way to enforceyour workflow, using a decentralized system requires more communicationand discipline to stick to the established of conventions. While this may seem like it induces overhead, I see benefit in the increased communication necessary to make it a good process. Your team will need to communicate about code, about changes and about project status in general.

我不会在这里谈论一般的优点/缺点，而是专注于您的上下文。人们普遍认为，与使用集中式系统相比，使用 DVCS 需要更有纪律的团队。这是因为集中式系统为您提供了一种简单的方法来执行您的工作流程，使用分散式系统需要更多的沟通和纪律来遵守既定的约定。虽然这似乎会导致开销，但我认为增加必要的沟通是有益的，以使其成为一个良好的过程。您的团队需要就代码、变更和项目状态进行总体沟通。

Another dimension in the context of discipline is encouraging branching and experiments. Here's a quote from Martin Fowler's recent bliki entry on Version Control Tools, he has found a very concise description for this phenomenon.

学科背景下的另一个维度是鼓励分支和实验。这是 Martin Fowler 最近在 Version Control Tools 上的 bliki 条目的引述，他找到了对这种现象的非常简洁的描述。

DVCS encourages quick branching for experimentation. You can do branches in Subversion, but the fact that they are visible to all discourages people from opening up a branch for experimental work. Similarly a DVCS encourages check-pointing of work: committing incomplete changes, that may not even compile or pass tests, to your local repository. Again you could do this on a developer branch in Subversion, but the fact that such branches are in the shared space makes people less likely to do so.

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

DVCS enables flexible workflows because they provide changeset tracking via globally unique identifiers in a directed acyclic graph (DAG) instead of simple textual diffs. This allows them to transparently track the origin and history of a changeset, which can be quite important.

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

Workflows:

工作流程：

Larry Osterman (a Microsoft dev working on the Windows team) has a great blog postabout the workflow they employ at the Windows team. Most notably they have:

Larry Osterman（在 Windows 团队工作的 Microsoft 开发人员）有一篇很棒的博客文章，介绍了他们在 Windows 团队中使用的工作流程。最值得注意的是他们有：

• A clean, high quality code only trunk (master repo)
• All development happens on feature branches
• Feature teams have team repos
• They do regularily merge the latest trunk changes into their feature branch (Forward Integrate)
• Complete features must pass several quality gates e.g. review, test coverage, Q&A (repos on their own)
• If a feature is completed and has acceptable quality it is merged into the trunk (Reverse Integrate)

• 一个干净、高质量的代码主干（主存储库）
• 所有开发都发生在功能分支上
• 功能团队有团队仓库
• 他们会定期将最新的主干更改合并到他们的功能分支中（前向集成）
• 完整的功能必须通过几个质量关口，例如、测试覆盖率、问答（自行回购）
• 如果一个功能完成并具有可接受的质量，则将其合并到主干中（反向集成）

As you can see, having each of these repositories live on their own you can decouple different teams advancing at different paces. Also the possibility to implement a flexible quality gate system distinguishes DVCS from a CVCS. You can solve your permission issues at this level too. Only a handful of people should be allowed access to the master repo. For each level of the hierachy, have a seperate repo with the corresponding access policies. Indeed, this approach can be very flexible on the team level. You should leave it up to each team to decide wether they want to share their team repo among themselves or if they want a more hierachical approach where only the team lead may commit to the team repo.

如您所见，让这些存储库中的每一个都独立存在，您可以将不同的团队以不同的速度推进。DVCS 与 CVCS 的区别还在于，实施灵活的质量门系统的可能性。您也可以在此级别解决您的权限问题。应该只允许少数人访问主存储库。对于层次结构的每个级别，都有一个带有相应访问策略的单独存储库。事实上，这种方法在团队层面上非常灵活。你应该让每个团队决定他们是想要在他们自己之间共享他们的团队回购，还是他们想要一个更有层次的方法，只有团队领导可以提交团队回购。

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

（图片是从 Joel Spolsky 的hginit.com盗来的。）

One thing remains to be said at this point though:- even though DVCS provides great merging capabilities, this is nevera 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.

不过，在这一点上还有一件事要说：- 尽管 DVCS 提供了强大的合并功能，但这永远不能替代使用持续集成。即使在那个时候，你也有很大的灵活性：主干存储库的 CI、团队存储库的 CI、问答存储库等。

Git in an enterprise context:

企业环境中的 Git：

Git is maybe not the ideal solution for an enterprise context as you have already pointed out. Repeating some of your concerns, I think most notably they are:

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

• Still somewhat immature support on Windows (please correct me if that changed recently)Now windows has github windows client, tortoisegit, SourceTree from atlassian
• Lack of mature GUI tools, no first class citizen vdiff/merge tool integration
• Inconsistent interface with a very low level of abstractions on top of its inner workings
• A very steep learning curve for svn users
• Git is very powerful and makes it easyto modify history, very dangerous if you don't know what you are doing (and you will sometimes even if you thought you knew)
• No commercial support options available

• Windows 上的支持仍然有些不成熟（如果最近发生了变化，请纠正我）现在 windows 有github windows 客户端，tortoisegit，来自 atlassian 的 SourceTree
• 缺乏成熟的 GUI 工具，没有一流的 vdiff/merge 工具集成
• 不一致的接口，在其内部工作之上具有非常低的抽象级别
• svn 用户的学习曲线非常陡峭
• Git 非常强大，可以轻松修改历史记录，如果您不知道自己在做什么，则非常危险（有时即使您认为自己知道）
• 没有可用的商业支持选项

I don't want to start a git vs. hg flamewar here, you have already done the right step by switching to a DVCS. Mercurial addresses some of the points above and I think it is therefore better suited in an enterprise context:

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

• All plattforms that run python are supported
• Great GUI tools on all major plattforms (win/linux/OS X), first class merge/vdiff tool integration
• Very consistent interface, easy transition for svn users
• Can do most of the things git can do too, but provides a cleaner abstraction. Dangerous operations are are always explicit. Advanced features are provided via extensions that must explicitly be enabled.
• Commercial support is availablefrom selenic.

• 支持所有运行python的平台
• 所有主要平台 (win/linux/OS X) 上的优秀 GUI 工具，一流的合并/vdiff 工具集成
• 非常一致的界面，svn用户轻松过渡
• 可以做 git 也可以做的大部分事情，但提供了更清晰的抽象。危险操作总是显式的。高级功能通过必须显式启用的扩展提供。
• selenic提供商业支持。

In short, when using DVCS in an enterprise I think it's important to choose a tool that introduces the least friction. For the transition to be successful it's especially important to consider the varying skill between developers (in regards to VCS).

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

---

---

Reducing friction:

减少摩擦：

Ok, since you appear to be really stuck with the situation, there are two options left IMHO. There is no tool to make git less complicated; git iscomplicated. Either you confront this or work around git:-

好吧，既然你似乎真的被这种情况困住了，恕我直言，还有两个选择。没有工具可以让 git 不那么复杂；git很复杂。你要么面对这个问题，要么解决 git:-

1. Get a git introductory course for the whole team. This should include the basics only and some exercises (important!).
2. Convert the master repo to svn and let the "young-stars" git-svn. This gives most of the developers an easy to use interface and may compensate for the lacking discipline in your team, while the young-stars can continue to use git for their own repos.

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

To be honest, I think you really have a people problem rather than a tool problem. What can be done to improve upon this situation?

老实说，我认为您确实存在人员问题而不是工具问题。可以做些什么来改善这种情况？

• 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).

• 您应该明确表示您认为您当前的流程最终会得到一个可维护的代码库。
• 花一些时间在持续集成上。正如我上面概述的那样，无论您使用哪种 VCS，CI 都没有替代品。你说有些人将垃圾推入主存储库：让他们在红色警报响起时修复他们的垃圾并指责他们破坏构建（或不符合质量指标或其他）。

回答by ebneter

I'm the SCM engineer for a reasonably large development organization, and we converted to git from svn over the last year or so. We use it in a centralized fashion.

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

We use gitosisto host the repositories. We broke our monolithic svn repositories up into many smaller git repositories as git's branching unit is basically the repository. (There are ways around that, but they're awkward.) If you want per-branch kinds of access controls, gitolitemight be a better approach. There's also an inside-the-firewall version of GitHubif you care to spend the money. For our purposes, gitosis is fine because we have pretty open permissions on our repositories. (We have groups of people who have write access to groups of repositories, and everyone has read access to all repositories.) We use gitweb for a web interface.

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

As for some of your specific concerns:

至于你的一些具体问题：

• merges: You can use a visual merge tool of your choice; there are instructions in various places on how to set it up. The fact that you can do the merge and check its validity totally on your local repo is, in my opinion, a major plus for git; you can verify the merge before you push anything.
• GUIs: We have a few people using TortoiseGit but I don't really recommend it; it seems to interact in odd ways with the command line. I have to agree that this is an area that needs improvement. (That said, I am not a fan of GUIs for version control in general.)
• small-group tracking branches: If you use something that provides finer-grained ACLs like gitolite, it's easy enough to do this, but you can also create a shared branch by connecting various developers' local repositories — a git repo can have multiple remotes.

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

We switched to git because we have lots of remote developers, and because we had many issues with Subversion. We're still experimenting with workflows, but at the moment we basically use it the same way as we used to use Subversion. Another thing we liked about it was that it opened up other possible workflows, like the use of staging repositories for code review and sharing of code among small groups. It's also encouraged a lot of people to start tracking their personal scripts and so forth because it's so easy to create a repository.

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

回答by hasen

Yes, I know, Linus never intended it for that.

是的，我知道，Linus 从来没有打算这样做。

Actually, Linus argues that centralized systems just can't work.

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

And, what's wrong with the dictator-and-lieutenants workflow?

而且，独裁者和中尉的工作流程有什么问题？

Remember, git is a distributedsystem; don't try to use it like a central one.

请记住，git 是一个分布式系统；不要试图把它当作一个中心来使用。

(updated)

（更新）

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).

如果您不尝试使用 git，就好像它是“类固醇上的 svn”一样（因为它不是），那么您的大多数问题都会消失。

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.

与其使用裸存储库作为中央服务器，每个人都可以推送（并且可能会搞砸），而是设置一些处理合并的集成管理器，以便只有他们可以推送到裸存储库。

Usually these people should be the team leads: each leader integrates his own team's work and pushes it to the blessed repository.

通常这些人应该是团队的leader：每个leader整合自己团队的工作，推送到blessed repository。

Even better, someone else (i.e. dictator) pulls from the team leaders and integrates their changes into the blessed repository.

更好的是，其他人（即独裁者）从团队领导者那里提取并将他们的更改集成到受祝福的存储库中。

There's nothing wrong with that workflow, but we're an overworked startup and need our tools to substitute for human time and attention; nobody has bandwidth to even do code reviews, let alone be benevolent dictator.

该工作流程没有任何问题，但我们是一家过度劳累的初创公司，需要我们的工具来替代人工时间和注意力；没有人有足够的空间来进行代码，更不用说成为仁慈的独裁者了。

If the integrators don't have time to review code, that's fine, but you still need to have people that integrate the merges from everybody.

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

Doing git pulls doesn't take all that much time.

做 git pulls 不需要花那么多时间。

git pull A
git pull B
git pull C

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

git确实替代了人类的时间和注意力；这就是为什么它首先被写出来。

• The GUI tools aren't mature

• GUI工具不成熟

The gui tools can handle the basic stuff pretty well.

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

Advanced operations require a coder/nerdy mindset (e.g. I'm comfortable working from the command line). It takes a bit of time to grasp the concepts, but it's not that hard.

高级操作需要程序员/书呆子的心态（例如，我很习惯从命令行工作）。掌握概念需要一些时间，但并不难。

• Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes

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

This won't be a problem unless you have many incompetent developers with full write access to the "central repository".

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

But, if you set up your workflow so that only a few people (integrators) write to the "blessed" repository, that won't be a problem.

但是，如果您将工作流程设置为只有少数人（集成商）写入“blessed”存储库，那将不成问题。

Git doesn't make it easy to screw up merges.

Git 不会轻易搞砸合并。

When there are merge conflicts, git will clearly mark the conflicting lines so you know which changes are yours and which are not.

当出现合并冲突时，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.

使用 svn 或任何其他（非分布式）工具删除其他人的代码也很容易。事实上，使用这些其他工具要容易得多，因为您倾向于长时间“坐视变化”，并且在某些时候合并会变得非常困难。

And because these tools don't know how to merge, you end up always having to merge things manually. For example, as soon as someone makes a commit to a file you're editing locally, it will be marked as a conflict that needs to be manually resolved; now thatis a maintenance nightmare.

而且由于这些工具不知道如何合并，因此您最终总是不得不手动合并内容。例如，只要有人提交了您在本地编辑的文件，它就会被标记为需要手动解决的冲突；现在这是一个维护噩梦。

With git, most of the time there won't be any merge conflicts because git can actually merge. In the case where a conflict does occur, git will clearly mark the lines for you so you know exactlywhich changes are yours and which changes are from other people.

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

If someone obliterates other people's changes while resolving a merge conflict, it won't be by mistake: it will either be because it was necessary for the conflict resolution, or because they don't know what they're doing.

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

• It doesn't offer per-user repository permissions beyond global read-only or read-write privileges

• If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.

• Workflows other than "anything goes" or "benevolent dictator" are hard to encourage, let alone enforce

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

• 如果您对存储库的任何部分都有权限，则可以对存储库的每个部分执行相同的操作，因此您无法执行其他人无法在中央服务器上创建小组跟踪分支之类的操作惹。

• 除了“一切顺利”或“仁慈的独裁者”之外的工作流程都很难鼓励，更不用说强制执行了

These problems will go away when you stop trying to use git as if it was a centralized system.

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

• 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).

• 目前尚不清楚使用单个大存储库（这让每个人都把所有东西都弄乱）还是使用大量每个组件的存储库（这会导致尝试同步版本的麻烦）更好。

Judgment call.

审判号召。

What kind of projects do you have?

你有什么样的项目？

For example: does version x.y of project A depend on exactly version w.z of project B such that every timeyou check x.y of project A you also have to checkout w.z of project B, otherwise it won't build? If so I'd put both project A and project B in the same repository, since they're obviously two parts of a single project.

例如：项目 A 的 xy 版本是否完全依赖于项目 B 的 wz 版本，这样每次检查项目 A 的 xy 时，您还必须检查项目 B 的 wz，否则它不会构建？如果是这样，我会将项目 A 和项目 B 放在同一个存储库中，因为它们显然是单个项目的两个部分。

The best practice here is to use your brain

这里最好的做法是用你的大脑

• With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.

• 对于多个存储库，也不清楚如何通过从中央存储库中提取来复制其他人拥有的所有源，或者执行诸如获取昨天下午 4:30 之前的所有内容之类的操作。

I'm not sure what you mean.

我不确定你是什么意思。

回答by Russell Mull

I highly recommend http://code.google.com/p/gerrit/for enterprise work. It gives you access control plus a built-in review based workflow. It authenticates against any LDAP system. You can hook it up to Hudson with http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin, letting you build and test changes while they're still under review; it's a really impressive setup.

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

If you decide to use gerrit, I recommend trying to keep a pretty linear history, not a branchy history like some of the open source guys like. Gerrit phrases this as "allow fast-forward changes only." Then you can use branching and merging in more the the way you're used to, for releases and whatnot.

如果您决定使用 gerrit，我建议您尝试保留一个非常线性的历史记录，而不是像某些开源人员那样的分支历史记录。Gerrit 将此表述为“仅允许快进更改”。然后，您可以按照习惯的方式使用分支和合并，用于发布等。

回答by Bruno Bossola

I am answering this question based on my experience as developer manager in a large telco, where we adopted Git in 2010

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

You have quite different set of problems here:

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

• workflows
• client tools
• server access control and integration

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

Workflows

工作流程

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.

我们成功地采用了中央存储库模式：我们在企业项目（一个拥有 500 万用户群的大型门户）中拥有的是一个事实上的中央存储库，它生成官方构建然后通过交付过程（在我们的案例，由三个级别的测试和两个部署组成）。每个开发人员都管理自己的存储库，我们在每个功能的基础上工作。

Client tools

客户端工具

There are now several options available, this is now a very crowded area. Many developers are successfully using IntelliJ Ideaand Eclipse with the Git plugin, without any other stuff. Also most of the Linux developers are using CLI git client, without any problem. Some Mac developers are successfully using Tower Git. Please note that none of these clientscan prevent the user to "mess up" with the central repository: a server side control mechamism is needed

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

Server access control and integration

服务器访问控制和集成

If you want to avoid developers "messing up" you Git repository, you reall need to choose a solution that:

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

• exposes a decent web admin interface to do every operation
• allows you to enforce user identities (using a "bare" Git repository is extremely easy to commit in behalf of someone else)
• provides you fine grained security (so that for example you can prevent FORCE-PUSH and set some branches to read only for some developers / groups)
• integrate with your corporate authentication system (i.e. LDAP, Windows ActiveDirectory)
• provides you full audit (SOX compliance is sometimes veryimportant for large corporates)

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

There are not so many ready-to-use server side solutions that can help this, I suggest you check out one of these:

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

• Gitorious: it can provide basic access level security, but it lacks fine grained permissions control out of the box, so you will probably have to do some coding to handle scenarios such as branch level permissions. It also lacks integration with existing corporate authentication mechanisms
• GitHubEnterprise: recently published by GitHub, it features GitHub in your corporate. It lacks SOX complianance and fine grained security
• Gerrit: it can provide fine graind access level security and integration with corporate authentication systems but it lacks SOX compliance and SSO. Also some operations can only be done via SSH via CLI
• GitEnterprise: it provides branch level permissions, SSO, SOX compliance, full web based administration. It was recently also integrated with Gerrit, so that it also provides you a full Gerrit instance

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

Hope this helps!

希望这可以帮助！

回答by lucamilanesio

On the tools, MacOS-X users find GitX (http://gitx.frim.nl/) very simple and effective. Drawback is that doesn't support Git Client hooks (the ones under $GIT_ROOT/.git/hooks).

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

Overall I do strongly to chose a tool that supports fine-grained access controlon: - branches (in order to segregate the stable release branches with strict security from the topic-branches that needs more agility and flexibility) - identity enforcement (author / committer). This is KEY for SOX- git commands restrictions - audit-trail. This is KEY for SOX

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

The ones I've successfully used with those features are:

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

1. Gerrit Code Review (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), uses Gerrit 2.1.8 behind the scenes

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

P.S. Do not underestimate SOX and CMMI compliance: many times there is limited set of choice you have that is dictated by your Company Enterprise Policies on Security.

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

Hope this helps.

希望这可以帮助。

Luca.

卢卡。

回答by Guillermo Garza

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 Vincent Driessen. For more info see these screencasts by David Bock, and this one by Mark Derricutt.

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

回答by John Nilsson

We recently switched from svn to git. Because git-daemon doesn't work with msysgit we opted for a central repository approach on a Linux server with gitosis.

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

To eliminate the possibility to screw up master we simply delted it. Instead we prepare all releases by merging the branches that are selected for testing and tag the merge. If it passes tests the commit is tagged with a version and put in production.

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

To handle this we have a rotating role of release manager. The release manager is responsible for reviewing each branch before it is ready for test. Then when the product ownder decides it is time to bundle the approved branches together for a new test release the release manager perform the merge.

为了解决这个问题，我们轮流担任发布经理。发布经理负责在每个分支准备好进行测试之前对其进行。然后，当产品所有者决定将批准的分支捆绑在一起以用于新的测试版本时，发布经理执行合并。

We also have a rotating role of 2'nd level help desk and at least for us the workload is such that it is possible to have both roles at the same time.

我们还有一个轮换的 2 级服务台角色，至少对我们来说，工作量是可以同时担任这两个角色的。

As a benefit of not having a master it is not possible to add any code to the project without going through the release manager so we discovered directly how much code that was silently added to the project before.

没有大师的好处是，不通过发布经理就无法向项目添加任何代码，因此我们直接发现了之前默默添加到项目中的代码量。

The review process starts with the branch owner submiting the diff to reviewboard and putting up a green post-it on the whiteboard with the branch name (we have a Kanban based workflow) under "for review", or if it's part of a completed user story, move the entire story card to "for review" and put the postit on that. The relase manager is the one who moves cards and post-its to "ready for test" and then the product owner can select which ones to incled in the next test release.

过程开始于分支机构所有者将差异提交到委员会并在白板上贴上绿色便利贴，在“”下带有分支机构名称（我们有一个基于看板的工作流程），或者如果它是已完成用户的一部分故事，将整个故事卡片移至“供”并在其上贴上便利贴。发布经理是将卡片和便利贴移动到“准备测试”的人，然后产品所有者可以选择将哪些卡片包含在下一个测试发布中。

When doing the merge the release manager also makes sure that the merge commit has a sensible commit message which can be used in the changelog for the product owner.

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

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.

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

回答by linquize

GUI: At the moment, TortoiseGit v1.7.6 should be fine for most daily operations. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, etc... Supports x64 natively too

图形界面：目前，TortoiseGit v1.7.6 应该可以满足大多数日常操作。日志、提交、推送、拉取、获取、差异、合并、分支、樱桃挑选、变基、标记、导出、存储、添加子模块等......也原生支持 x64

回答by William Cheung

In order to use git efficiently in a development team with lots of developers, a CI system that builds and tests continuously is required. Jenkins provides such a vehicle and I highly recommend that. The integration piece has to be done no matter what and it's a lot cheaper doing that earlier and more often.

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