您使用分布式版本控制吗？
我想听听使用分布式版本控制（又名分布式修订控制、分散版本控制）的人们的意见以及他们如何找到它。 你在使用什么，Mercurial、Darcs、Git、Bazaar？ 你还在用它吗？ 如果您过去使用过客户端/服务器 rcs，您是否发现它更好、更差或只是不同？ 你能告诉我什么才能让我跟上潮流吗？ 或者就此事而言，我也有兴趣听取有负面经历的人的意见。
我目前正在考虑更换我们当前的源代码控制系统（Subversion），这是这个问题的推动力。
我对与其他国家/地区的同事一起使用它的任何人特别感兴趣，在这些国家/地区，您的计算机可能不会同时打开，并且您的连接速度非常慢。
如果您不确定什么是分布式版本控制，这里有几篇文章：
I'd like to hear from people who are using distributed version control (aka distributed revision control, decentralized version control) and how they are finding it. What are you using, Mercurial, Darcs, Git, Bazaar? Are you still using it? If you've used client/server rcs in the past, are you finding it better, worse or just different? What could you tell me that would get me to jump on the bandwagon? Or jump off for that matter, I'd be interested to hear from people with negative experiences as well.
I'm currently looking at replacing our current source control system (Subversion) which is the impetus for this question.
I'd be especially interested in anyone who's used it with co-workers in other countries, where your machines may not be on at the same time, and your connection is very slow.
If you're not sure what distributed version control is, here are a couple articles:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（18）
我一直在工作和个人项目中使用 Mercurial，我对此非常满意。 我看到的优点是：
当然，就像任何新系统一样，过渡期间也有一些痛苦。 你必须以不同于使用 SVN 时的方式来思考版本控制，但总的来说，我认为这是非常值得的。
I've been using Mercurial both at work and in my own personal projects, and I am really happy with it. The advantages I see are:
Of course, like any new system, there was some pain during the transition. You have to think about version control differently than you did when you were using SVN, but overall I think it's very much worth it.
在我工作的地方，我们决定从 SVN 迁移到 Bazaar（在评估了 git 和 Mercurial 之后）。 Bazaar 很容易启动，命令很简单（不像 git 有 140 个命令）。
我们看到的优点是能够创建本地分支并在不干扰主版本的情况下对其进行工作。 由于无需网络访问也能工作，因此比较速度更快。
我喜欢 bzr 中的一项命令是搁置扩展。 如果您开始在单个文件中处理两段逻辑上不同的代码，并且只想提交其中一段，则可以使用搁置扩展来稍后搁置其他更改。 在 Git 中，您可以在索引（暂存区域）中执行相同的操作，但 bzr 有更好的 UI。
大多数人不愿意移动，因为他们必须输入两个命令来提交和推送（bzr ci + bzr Push）。 他们也很难理解分支和合并的概念（没有人在 svn 中使用分支或合并它们）。
一旦理解了这一点，就会提高开发人员的生产力。 在每个人都明白这一点之前，每个人之间都会出现不一致的行为。
At the place where I work, we decided to move from SVN to Bazaar (after evaluating git and mercurial). Bazaar was easy to start off, with simple commands (not like the 140 commands that git has)
The advantages that we see is the ability to create local branches and work on it without disturbing the main version. Also being able to work without network access, doing diffs is faster.
One command in bzr which I like is the shelve extension. If you start working on two logically different pieces of code in a single file and want to commit only one piece, you can use the shelve extension to literally shelve the other changes later. In Git you can do the same with playing around in the index(staging area) but bzr has a better UI for it.
Most of the people were reluctant to move over as they have to type in two commands to commit and push (bzr ci + bzr push). Also it was difficult for them to understand the concept of branches and merging (no one uses branches or merges them in svn).
Once you understand that, it will increase the developer's productivity. Till everyone understands that, there will be inconsistent behaviour among everyone.
在我的工作场所，我们大约两个月前从 CVS 切换到了 Git（我的大部分经验都是使用 Subversion）。 虽然熟悉分布式系统有一个学习曲线，但我发现 Git 在两个关键领域表现出色：工作环境的灵活性和合并。
我不必使用我们的 VPN，甚至根本不需要网络连接，就可以访问完整的版本控制功能。 这意味着当冲动袭来时，我可以随时随地尝试想法或进行大型重构，而不必记得检查我已经建立的巨大提交，也不必担心当我搞砸时无法恢复。
由于合并是在客户端执行的，因此它们比启动服务器端合并要快得多且不易出错。
At my workplace we switched to Git from CVS about two months ago (the majority of my experience is with Subversion). While there was a learning curve involved in becoming familiar with the distributed system, I've found Git to be superior in two key areas: flexibility of working environment and merging.
I don't have to be on our VPN, or even have network connectivity at all, to have access to full versioning capabilities. This means I can experiment with ideas or perform large refactorings wherever I happen to be when the urge strikes, without having to remember to check in that huge commit I've built up or worrying about being unable to revert when I make a mess.
Because merges are performed client-side, they are much faster and less error-prone than initiating a server-side merge.
我的公司目前使用 Subversion、CVS、Mercurial 和 git。
当我们五年前开始时，我们选择了 CVS，并且在我的部门中我们仍然使用它作为我们的主要开发和发布维护分支。 然而，我们的许多开发人员单独使用 Mercurial 作为一种拥有私有检查点的方式，而无需承受 CVS 分支（特别是合并它们）的痛苦，并且我们开始将 Mercurial 用于一些最多约 5 人的分支。 我们很有可能在一年内最终放弃 CVS。 我们对 Mercurial 的使用不断增长； 有些人甚至从来没有碰过它，因为他们对 CVS 很满意。 每个尝试过 Mercurial 的人最终都对它感到满意，并且没有太多的学习曲线。
Mercurial 对我们来说真正有效的是，我们的（自制的）持续集成服务器可以监控开发人员 Mercurial 存储库以及主线。 因此，人们提交到他们的存储库，让我们的持续集成服务器检查它，然后发布变更集。 我们支持很多平台，因此进行适当水平的手动检查是不可行的。 另一个胜利是合并通常很容易，当合并困难时，您可以获得做好合并工作所需的信息。 一旦有人让合并版本开始工作，他们就可以推送他们的合并变更集，然后其他人就不必重复这项工作。
最大的障碍是您需要重新连接开发人员和经理的大脑，以便他们摆脱单一线性分支模型。 对此最好的良药就是一剂 Linus Torvalds，告诉你你又蠢又丑 如果您使用集中式 SCM。 好的历史可视化工具会有所帮助，但我对可用的工具还不满意。
对于我们混合使用 Windows、Linux 和 Solaris 的开发人员来说，Mercurial 和 CVS 都工作得很好，而且我注意到时区没有问题。 （实际上，这并不太难；您只需在内部使用纪元秒，我希望所有主要的 SCM 系统都能做到这一点）。
经过相当多的努力，就有可能将我们的主线 CVS 历史导入到 Mercurial 中。 如果人们没有故意将极端情况引入我们的主线 CVS 历史记录中作为测试历史迁移工具的一种方式，事情会更容易。 这包括将一些 Mercurial 分支合并到 CVS 历史记录中，因此该项目看起来就像从第一天就开始使用一样。
我们的芯片设计团队选择了 Subversion。 它们距离我的办公室主要有 8 个时区，即使在我们办公室之间有一条相当好的专线，SUbversion 结帐也很痛苦，但可行。 集中式系统的一大优点是，您可以将大型二进制文件签入其中（例如供应商版本），而无需使所有分布式存储库变得庞大。
我们使用 git 来处理 Linux 内核。 一旦原生 Windows 版本成熟，Git 会更适合我们，但我认为 Mercurial 的设计是如此简单和优雅，所以我们会坚持使用它。
My company currently uses Subversion, CVS, Mercurial and git.
When we started five years ago we chose CVS, and we still use that in my division for our main development and release maintenance branch. However, many of our developers use Mercurial individually as a way to have private checkpoints without the pain of CVS branches (and particularly merging them) and we are starting to use Mercurial for some branches that have up to about 5 people. There's a good chance we'll finally ditch CVS in another year. Our use of Mercurial has grown organically; some people still never even touch it, because they are happy with CVS. Everyone who has tried Mercurial has ended up being happy with it, without much of a learning curve.
What works really nicely for us with Mercurial is that our (home brewed) continuous integration servers can monitor developer Mercurial repositories as well as the mainline. So, people commit to their repository, get our continuous integration server to check it, and then publish the changeset. We support lots of platforms so it is not feasible to do a decent level of manual checks. Another win is that merges are often easy, and when they are hard you have the information you need to do a good job on the merge. Once someone gets the merged version to work, they can push their merge changesets and then no one else has to repeat the effort.
The biggest obstacle is that you need to rewire your developers and managers brains so that they get away from the single linear branch model. The best medicine for this is a dose of Linus Torvalds telling you you're stupid and ugly if you use centralised SCM. Good history visualisation tools would help but I'm not yet satisfied with what's available.
Mercurial and CVS both work well for us with developers using a mix of Windows, Linux and Solaris, and I've noticed no problems with timezones. (Really, this isn't too hard; you just use epoch seconds internally, and I'd expect all the major SCM systems get this right).
It was possible, with a fair amount of effort, to import our mainline CVS history into Mercurial. It would have been easier if people had not deliberately introduced corner cases into our mainline CVS history as a way to test history migration tools. This included merging some Mercurial branches into the CVS history, so the project looks like it was using from day one.
Our silicon design group chose Subversion. They are mainly eight timezones away from my office, and even over a fairly good dedicated line between our offices SUbversion checkouts are painful, but workable. A big advantage of centralised systems is that you can potentially check big binaries into it (e.g. vendor releases) without making all the distributed repositories huge.
We use git for working with Linux kernel. Git would be more suitable for us once a native Windows version is mature, but I think the Mercurial design is so simple and elegant that we'll stick with it.
我自己没有使用分布式源代码控制，但也许这些相关的问题和答案会给您一些见解：
Not using distributed source control myself, but maybe these related questions and answers give you some insights:
我个人使用 Mercurial 源代码控制系统。 我现在已经使用它一年多了。 这实际上是我第一次体验 VSC。
我尝试过 Git，但从未真正投入使用，因为我发现它对于我的需要来说太多了。 如果您是 Subversion 用户，Mercurial 确实很容易上手，因为它与 Subversion 共享许多命令。 另外，我发现存储库的管理非常容易。
我有两种与人们共享代码的方式：
真的很容易使用，但非常强大。 但一般来说，选择 VSC 实际上取决于我们项目的需求......
I personnaly use Mercurial source control system. I've been using it for a bit more than a year right now. It was actually my first experience with a VSC.
I tried Git, but never really pushed into it because I found it was too much for what I needed. Mercurial is really easy to pick up if you're a Subversion user since it shares a lot of commands with it. Plus I find the management of my repositories to be really easy.
I have 2 ways of sharing my code with people:
Really easy to work with, yet very powerful. But generally, choosing a VSC really depends on our project's needs...
在我们关闭 Sun 工作站进行嵌入式系统开发之前，我们使用的是 Sun 的 TeamWare< /a> 解决方案。 TeamWare 是一个完全分发的解决方案，使用 SCCS 作为本地存储库文件修订系统，然后使用一组工具将其包装起来，以处理合并操作（通过分支重命名完成）回集中存储库（其中可以有很多）。 事实上，因为它是分布式的，所以本身实际上没有主存储库（除非按照惯例，如果您需要的话），并且所有用户都有自己的整个源代码树和修订版本的副本。 在“放回”操作期间，使用 3 路差异的合并工具通过算法对内容进行排序，并允许您组合不同开发人员随时间积累的更改。
在切换到 Windows 作为我们的开发平台后，我们最终切换到 AccuRev。 虽然 AccuRev 由于依赖于集中式服务器，所以并不是真正的分布式解决方案，但从逻辑上讲，它与工作流模型非常接近。 TeamWare 在每个客户端上拥有完全独立的所有内容副本，包括所有文件的所有修订版，而在 AccuRev 下，副本保存在中央数据库中，本地客户端计算机仅具有用于本地编辑的平面文件当前版本。 然而，这些本地副本可以通过与服务器的客户端连接进行版本控制，并与其他开发人员隐式创建的任何其他更改（即：分支）完全分开进行跟踪。 就我
个人而言，我认为由 TeamWare 实现的分布式模型或由 TeamWare 实现的混合模型AccuRev 优于完全集中式解决方案。 其主要原因是不存在必须检出文件或让其他用户锁定文件的概念。 此外，用户不必创建或定义分支； 这些工具会隐式地为您执行此操作。 当有较大的团队或不同的团队贡献或维护一组源文件时，这可以解决“工具生成的”锁定相关冲突，并允许在开发人员级别更多地协调代码更改，而开发人员最终必须协调更改。 从某种意义上说，分布式模型允许更细粒度的“锁”，而不是集中式模型建立的粗粒度锁定。
Back before we switched off of Sun workstations for embedded systems development we were using Sun's TeamWare solution. TeamWare is a fully distribution solution using SCCS as the local repository file revision system and then wrappers that with a set of tools to handle the merging operations (done through branch renaming) back to the centralized repositories of which there can be many. In fact, because it is distributed, there really is no master repository per se' (except by convention if you want it) and all users have their own copies of the entire source tree and revisions. During "put back" operations, the merge tool using 3-way diffs algorithmically sorts out what is what and allows you combine the changes from different developers that have accumulated over time.
After switching to Windows for our development platform, we ended up switching to AccuRev. While AccuRev, because it depends on a centralized server, is not truely a distributed solution, logically from a workflow model comes very close. Where TeamWare would have had completely seperate copies of everything at each client, including all the revisions of all files, under AccuRev this is maintained in the central database and the local client machines only have the flat file current version of things for editing locally. However these local copies can be versioned through the client connection to the server and tracked completely seperately from any other changes (ie: branches) implicitly created by other developers
Personally, I think the distributed model implemented by TeamWare or the sort of hybrid model implemented by AccuRev is superior to completely centralized solutions. The main reason for this is that there is no notion of having to check out a file or having a file locked by another user. Also, users don't have to create or define the branches; the tools do this for you implicitly. When there are larger teams or different teams contributing to or maintaining a set of source files this resolves "tool generated" locking related collisions and allows the code changes to be coordinated more at the developer level who ultimately have to coordinate changes anyway. In a sense, the distributed model allows for a much finer grained "lock" rather than the course grained locking instituted by the centralized models.
在一个大项目（GHC）和许多小项目中使用过 darcs。 我对达尔克斯有着又爱又恨的关系。
优点：设置存储库非常容易。 在存储库之间移动更改非常容易。 非常容易克隆并在单独的存储库中尝试“分支”。 在小的、连贯的团体中很容易做出有意义的“承诺”。 很容易重命名文件和标识符。
缺点：没有历史概念——你无法恢复“8 月 5 日的情况”。 我从来没有真正弄清楚如何使用darcs回到早期版本。
破坏交易的因素：darcs 无法扩展。 我（和许多其他人）在使用 Darcs 的 GHC 中遇到了大麻烦。 我已经让它以 100% CPU 使用率挂起 9 天了，试图拉入
3个月的改变。 去年夏天我经历了一次糟糕的经历，我损失了两周的时间
尝试使 darcs 发挥作用，并最终求助于手动将所有更改重播到原始存储库中。
结论：如果您想要一种简单、轻量级的方法来避免自己为自己的爱好项目搬起石头砸自己的脚，darcs 是很棒的选择。 但即使 darcs 2 中解决了一些性能问题，它仍然不适合工业强度的东西。 我不会真正相信达尔克，除非被吹嘘的“补丁理论”不仅仅是几个方程和一些漂亮的图片； 我希望看到一个真实的理论在经过评审的场所发表。 已经过去了。
Have used darcs on a big project (GHC) and for lots of small projects. I have a love/hate relationship with darcs.
Pluses: incredibly easy to set up repository. Very easy to move changes around between repositories. Very easy to clone and try out 'branches' in separate repositories. Very easy to make 'commits' in small coherent groups that makes sense. Very easy to rename files and identifiers.
Minuses: no notion of history---you can't recover 'the state of things on August 5'. I've never really figured out how to use darcs to go back to an earlier version.
Deal-breaker: darcs does not scale. I (and many others) have gotten into big trouble with GHC using darcs. I've had it hang with 100% CPU usage for 9 days trying to pull in
3 months' worth of changes. I had a bad experience last summer where I lost two weeks
trying to make darcs function and eventually resorted to replaying all my changes by hand into a pristine repository.
Conclusion: darcs is great if you want a simple, lightweight way to keep yourself from shooting yourself in the foot for your hobby projects. But even with some of the performance problems addressed in darcs 2, it is still not for industrial strength stuff. I will not really believe in darcs until the vaunted 'theory of patches' is something a bit more than a few equations and some nice pictures; I want to see a real theory published in a refereed venue. It's past time.
我真的很喜欢 Git，尤其是 GitHub。 能够在本地提交和回滚真是太好了。 挑选合并虽然不简单，但也不是特别困难，而且比 Svn 或 CVS 能做的任何事情都要先进得多。
I really love Git, especially with GitHub. It's so nice being able to commit and roll back locally. And cherry-picking merges, while not trivial, is not terribly difficult, and far more advanced than anything Svn or CVS can do.
我的团队正在使用 Git，这带来了天壤之别。 我们使用 SCCS 和大量 csh 脚本来管理相当大且复杂的项目，这些项目在它们之间共享代码（无论如何尝试）。
使用 Git，子模块支持使很多事情变得简单，并且只需要最少的脚本编写。 我们的发布工程工作已经大大减少，因为分支很容易维护和跟踪。 能够以低成本进行分支和合并确实使得在多个项目（合同）中维护单个源集合变得相当容易，而在此之前，对典型事物流程的任何破坏都非常非常昂贵。 我们还发现 Git 的脚本能力是一个巨大的优势，因为我们可以通过钩子或通过执行
的脚本来自定义其行为。 git-sh-setup，看起来不像以前那样是一堆拼凑的东西。有时我们也会遇到这样的情况：我们必须跨分布式、非联网站点（在本例中为断开连接的安全实验室）维护版本控制，而 Git 具有可以相当顺利地处理该问题的机制（捆绑包、基本克隆机制、格式化的补丁等）。
其中一些只是我们走出了 80 年代初并采用了一些现代版本控制机制，但 Git 在大多数领域“都做得对”。
我不确定您正在寻找的答案的范围，但我们使用 Git 的经验非常非常积极。
My group at work is using Git, and it has been all the difference in the world. We were using SCCS and a steaming pile of csh scripts to manage quite large and complicated projects that shared code between them (attempted to, anyway).
With Git, submodule support makes a lot of this stuff easy, and only a minimum of scripting is necessary. Our release engineering effort has gone way, way down because branches are easy to maintain and track. Being able to cheaply branch and merge really makes it reasonably easy to maintain a single collection of sources across several projects (contracts), whereas before, any disruption to the typical flow of things was very, very expensive. We've also found the scriptabability of Git to be a huge plus, because we can customize its behavior through hooks or through scripts that do
. git-sh-setup, and it doesn't seem like a pile of kludges like before.We also sometimes have situations in which we have to maintain our version control across distributed, non-networked sites (in this case, disconnected secure labs), and Git has mechanisms for dealing with that quite smoothly (bundles, the basic clone mechanism, formatted patches, etc).
Some of this is just us stepping out of the early 80s and adopting some modern version control mechanisms, but Git "did it right" in most areas.
I'm not sure of the extent of answer you're looking for, but our experience with Git has been very, very positive.
将 Subversion 与 SourceForge 和其他服务器一起使用，通过许多不同的连接与中型团队合作，效果非常好。
Using Subversion with SourceForge and other servers over a number of different connections with medium sized teams and it's working very well.
出于很多原因，我是集中式源代码控制的大力支持者，但我确实在一个项目上短暂尝试过 BitKeeper。 也许在使用一种或另一种格式的集中式模型（Perforce、Subversion、CVS）多年之后，我发现分布式源代码控制很难使用。
我认为我们的工具永远不应该妨碍实际工作； 他们应该让工作变得更容易。 所以，在经历了几次令人头疼的经历之后，我放弃了。 我建议在破坏之前与您的团队一起进行一些非常严格的测试，因为该模型与 SCM 世界中大多数开发人员可能习惯的模型非常不同。
I am a huge proponent of centralized source control for a lot of reasons, but I did try BitKeeper on a project briefly. Perhaps after years of using a centralized model in one format or another (Perforce, Subversion, CVS) I just found distributed source control difficult to use.
I am of the mindset that our tools should never get in the way of the actual work; they should make work easier. So, after a few head pounding experiences, I bailed. I would advise doing some really hardy tests with your team before rocking the boat because the model is very different than what most devs are probably accustomed to in the SCM world.
我已经使用 bazaar 一段时间了，并且喜欢它。 简单的分支和合并让我们对使用分支有很大的信心。 （我知道中央 vcs 工具应该允许这样做，但是包括 subversion 在内的常见工具不允许这样做）。
bzr 支持多种不同的工作流程，从单独工作到作为集中存储库工作到完全分布式工作。 由于每个分支（对于开发人员或功能）都可以独立合并，因此可以在每个分支的基础上进行代码审查。
bzr 还有一个很棒的插件 (bzr-svn)，允许您使用 subversion 存储库。 您可以复制 svn 存储库（最初需要一段时间，因为它会获取本地存储库的整个历史记录）。 然后您可以为不同的功能创建分支。 如果您想在功能完成一半时对主干进行快速修复，您可以创建一个额外的分支，在其中工作，然后合并回主干，使完成一半的功能保持不变并保留在主干之外。 精彩的。 到目前为止，反对颠覆一直是我的主要用途。
注意，我只在 Linux 上使用过它，并且主要是从命令行使用它，尽管它应该在其他平台上运行良好，但具有诸如 TortoiseBZR 并且正在与 IDE 集成 进行大量工作> 等等。
I've used bazaar for a little while now and love it. Trivial branching and merging back in give great confidence in using branches as they should be used. (I know that central vcs tools should allow this, but the common ones including subversion don't allow this easily).
bzr supports quite a few different workflows from solo, through working as a centralised repository to fully distributed. With each branch (for a developer or a feature) able to be merged independently, code reviews can be done on a per branch basis.
bzr also has a great plugin (bzr-svn) allowing you to work with a subversion repository. You can make a copy of the svn repo (which initially takes a while as it fetches the entire history for your local repo). You can then make branches for different features. If you want to do a quick fix to the trunk while half way through your feature, you can make an extra branch, work in that, and then merge back to trunk, leaving your half done feature untouched and outside of trunk. Wonderful. Working against subversion has been my main use so far.
Note I've only used it on Linux, and mostly from the command line, though it is meant to work well on other platforms, has GUIs such as TortoiseBZR and a lot of work is being done on integration with IDEs and the like.
我正在为我的家庭项目使用 Mercurial。 到目前为止，我喜欢它的是我可以拥有多个存储库。 如果我把笔记本电脑带到机舱，我仍然可以进行版本控制，这与我在家里运行 CVS 时不同。 分支就像
hg clone一样简单并在克隆上工作。I'm playing around with Mercurial for my home projects. So far, what I like about it is that I can have multiple repositories. If I take my laptop to the cabin, I've still got version control, unlike when I ran CVS at home. Branching is as easy as
hg cloneand working on the clone.Subversion 不是分布式的，所以这让我觉得我需要一个维基百科链接，以防人们不确定我在说什么:)
Subversion isn't distributed, so that makes me think I need a wikipedia link in case people aren't sure what I'm talking about :)
一直在使用darcs 2.1.0，它非常适合我的项目。 便于使用。 喜欢樱桃采摘的变化。
Been using darcs 2.1.0 and its great for my projects. Easy to use. Love cherry picking changes.
我在工作中和我的一位同事一起使用 Git。 不过，主要存储库是 SVN。 我们经常需要切换工作站，而 Git 可以非常轻松地从另一台计算机上的本地存储库中提取更改。 当我们作为一个团队致力于同一功能时，合并我们的工作是毫不费力的。
git-svn 桥有点不稳定，因为在签入 SVN 时，它会重写所有提交以添加其 git-svn-id 注释。 这破坏了我同事的仓库和我的仓库之间合并的美好历史。 我预测，如果每个团队成员都使用 Git，我们根本就不会使用中央存储库。
你没有说你在什么操作系统上开发，但是Git的缺点是你必须使用命令行来获取所有功能。 Gitk 是一个很好的图形用户界面，用于可视化合并历史记录，但合并本身必须手动完成。 Git-Gui 和 Visual Studio 插件还没有那么完善。
I use Git at work, together with one of my coworkers. The main repository is SVN, though. We often have to switch workstations and Git makes it very easy to just pull changes from a local repository on another machine. When we're working as a team on the same feature, merging our work is effortless.
The git-svn bridge is a little wonky, because when checking into SVN it rewrites all the commits to add its git-svn-id comment. This destroys the nice history of merges between my coworker's repo an mine. I predict that we wouldn't use a central repository at all if every teammember would be using Git.
You didn't say what os you develop on, but Git has the disadvantage that you have to use the command line to get all the features. Gitk is a nice gui for visualizing the merge history, but the merging itself has to be done manually. Git-Gui and the Visual Studio plugins are not that polished yet.
我们对多站点和离线场景使用分布式版本控制（Plastic SCM）。
1- 多站点：如果您有遥远的团体，有时您不能依赖互联网连接，或者它不够快并减慢开发人员的速度。 然后拥有可以同步回来的独立服务器（塑料来回复制分支）是非常有用的并且可以加快速度。 这可能是公司最常见的场景之一，因为大多数公司仍然关注“完全分布式”实践，其中每个开发人员都有自己的复制存储库。
2- 断开连接（如果您愿意，也可以是真正的分布式）：每个开发人员都有自己的存储库，该存储库与他的同行或中央位置来回复制。 非常方便地前往客户所在地或只需携带笔记本电脑回家，并继续能够切换分支机构、结账和签入代码、查看历史记录、运行注释等，而无需访问远程“中心”服务器。 然后，每当您返回办公室时，只需单击几下即可将更改（通常是分支）复制回来。
We use distributed version control (Plastic SCM) for both multi-site and disconnected scenarios.
1- Multi-site: if you have distant groups, sometimes you can't rely on the internet connection, or it's not fast enough and slows down developers. Then having independent server which can synchronize back (Plastic replicates branches back and forth) is very useful and speed up things. It's probably one of the most common scenarios for companies since most of them are still concerned of "totally distributed" practices where each developer has its own replicated repository.
2- Disconnected (or truly distributed if you prefer): every developer has his own repository which is replicated back and forth with his peers or the central location. It's very convenient to go to a customer's location or just go home with your laptop, and continue being able to switch branches, checkout and checkin code, look at the history, run annotates and so on, without having to access the remote "central" server. Then whenever you go back to the office you just replicate your changes (normally branches) back with a few clicks.