分布式版本控制“杀手级应用程序”
考虑切换到 Mercurial 或 Git？我们也是。 我目前正在研究 DVCS 的好处，结果证明这是巨大的、欲望和必须的。
我很想听听社区的典型使用模式。
让我们为 DVCS 创建“前 N 个”生产力功能列表（基于 Mercurial、Git 或类似功能）。
请描述被证明对您/您的团队高效的工作流程、DVCS 帮助您实现/改进的程序以及 DVCS 为您提供的直白的“好东西”（不要假设这些东西对新手用户来说是清楚的）。
我认为这样的列表可以帮助人们向团队提出 DVCS 建议。
显然，这个问题是社区维基。
Considering switching to Mercurial or Git? We are too.
I'm currently studying the benefits of DVCS which turn out to be vast, lust and must.
I would love to hear from the community typical usage patterns.
Let's create a "Top N" productivity feature list for DVCS (based on Mercurial, Git or alike).
Please describe work flows that prove to be productive for you / your team, procedures that DVCS helped you achieve/improve as well as blunt "good stuff" that DVCS gives you (don't assume stuff are clear to the novice user).
I think that such a list could help folks approaching the team with a DVCS suggestion.
This question is community wiki, obviously.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
一个真正的杀手级功能是...
合并
DVCS（Git、Mercurial 或其他）是为合并而设计的（正是因为分布式，合并是允许这些工具快速集成代码的关键功能）来自各种远程存储库）。
SVN 无法胜任这项任务（即使在今天）。
请参阅：
The one true actual killer feature is...
merging
DVCS (Git, Mercurial or other) are made for merging (precisely because, being distributed, merging is the key feature allowing those tools to quickly integrate code coming from various remote repositories).
SVN isn't up to the task (even today).
See:
提交与发布分离
这对于较大的功能来说很重要，因为这意味着人们可以通过一系列提交来实现一项功能（每个提交都很小且独立） ，通过平分历史来轻松找到错误）到自己满意的程度，并且只有当他们准备好发布它们时。
这种方法的一个变体是拥有单独的公共存储库，其中包含正在进行的工作的可重设分支，并且仅当分支准备好接受检查时才推送（或发送拉取请求）。
Separation of committing from publishing
This is important for larger features, because it means that one can work on a series of commits to implement a feature (each commit being small and self contained, for easy finding bugs by bisecting history) to one own satisfaction, and only when they are ready to publish them.
A variant of this approach is to have separate public repository with rebasable branch with work in progress, and push (or send a pull request) only when branch is ready for inspection.
对我们来说，“杀手级应用”似乎将成为逐级推送代码的可能性。
我们将拥有 DEV 存储库，所有开发人员都在推动它。
QA 存储库将接受来自 DEV 存储库的推送，并构建其代码版本以进行测试。测试完成后，他们会将代码推送到生产存储库（QA 存储库是唯一可以将更改推送到生产存储库的存储库），从中构建“生产”版本。
Joel 的 hginit（靠近页面底部）对此进行了简要概述。
一旦我们实际实现了上述设置，我将更新这篇文章。
It seems that for us the "killer app" will turn to be the possibility to push code through stages.
We will have DEV repo, which all the devs are pushing into it.
QA repo will accept push from the DEV repo and will build it's version of the code for testing. Once testing is complete they will push the code to Production repo (QA repo is the only one that can push changes to the production repo) from which a "production" release will be build.
This is outlined briefly in Joel's hginit (near the bottom of the page).
I will update this post once we actually implemented the described above setup.
对于OSS项目：
贡献门槛低
首先，大多数DVCS都有出色的工具来处理补丁（通常通过电子邮件发送），既可以创建补丁也可以应用补丁。贡献者可以使用任何工具创建补丁（尽管最好使用项目使用的 DVCS 创建补丁，因为某些 DVCS 在补丁中添加额外信息），并将其发送到项目的邮件列表，或直接发送给项目维护者，或将其附加到问题跟踪器中的错误报告/功能请求中。
其次，您不需要提交位就可以做出贡献。只需克隆项目存储库，您就可以使用 DVCS 的全部功能。然后，您可以发送补丁、拉取请求或推送到“mob”分支；有很多可能性。
这对于项目维护者来说也是一个优势：他/她不必担心他/她可以信任谁来提供“提交位”，即访问存储库，就像 CVCS 中的情况一样。 Karl Fogel 在《生产开源软件》中写道。如何运行一个成功的自由软件项目。他发现访问控制等限制最好是社会性的而不是技术性的，对项目来说更好； DVCS 更进一步，因为不需要决定是否提供提交许可。
For OSS projects:
low entry barrier to contribute
First, most DVCS has excellent tools to work with patches (usually sent by email), both to create them and to apply them. The contributor can create a patch using any tools (although it would be best to create patch with DVCS used by project, as some DVCS put extra information in patches), and send it to mailing list of a project, or directly to project maintainer, or attach it to the bug report / feature request in an issue tracker.
Second, you don't need commit bit to be able to contribute. Just clone project repository, and you can use full power of DVCS. You can then send patches, or a pull request, or push to 'mob' branch; there are many possibilities.
It is an advantage also for project maintainer(s): he/she doesn't have to worry who can he/she trust to give "commit bit", i.e. access to repository, as it is the case in CVCS. Karl Fogel wrote in Producing Open Source Software. How to Run a Successful Free Software Project. that he found it better for the project that restrictions such as access control better be social rather than technological; DVCS takes it further thanks to not requiring to decide whether to provide permission to commit.
大多数功能都可以离线使用
使用 Subversion 等集中式 VCS，离线时您唯一能做的就是编辑内容。某些系统确实提供对其他功能的有限访问（例如，在 Subversion 中，您可以从存储库比较并恢复到最新版本），但 VCS 的大部分有用之处在于，
是唯一可能的如果您连接到中央服务器。
使用 DVCS，上述所有操作都在本地进行，如果某些内容需要进入中央服务器，您可以稍后在再次上线时将其推送到那里。
虽然如果您始终在线（例如在办公室），这可能并不重要，但如果您经常必须离线工作（例如在旅行时或在家中连接不稳定），则这一点可能很重要。
我开始专门使用 git 是因为我经常在路上工作并且通常没有（可靠的）连接。
Most functionality is available offline
With centralised VCS like Subversion, the only thing you can do when offline is edit stuff. Some systems do give limited access to other functionality (e.g. in Subversion you can diff to and revert to the latest version from the repo), but most of what makes VCS useful, that is
is only possible if you are connected to the central server.
With a DVCS, all the operations above work locally, and if something needs to go into the central server, you can always push it there later, when you are online again.
While this is probably unimportant if you are always online (such as at the office), it can be critical if you often have to work offline, such as while traveling or at home with a flaky connection.
I started using git specifically because I often work on the road and usually don't have a (reliable) connection.
“杀手级应用程序”似乎是分布式团队：每个团队都可以拥有自己的存储库并根据需要推送更改，而不是绑定到中央服务器（通过缓慢或不可靠的连接）。
The "killer app" seems to be distributed teams: rather than being tied to a central server (over a slow or unreliable connection), each team can have its own repository and push changes as needed.
无需发布即可与他人共享更改
对于我来说，当我是一个大型团队时，杀手级应用程序能够与其他工程师一起工作，共享更改，而无需通过中央服务器。这意味着我们可以以受控的方式共享未完成的功能（即无需“从我的树中复制此文件”），并且一切都正常。
Sharing changes with others without publishing
For me the killer app, when I was a large team, was being able to work together with other engineers, sharing changes, without needing to go through the central server. It meant we could share unfinished features in a controlled way (i.e. no "copy this file from my tree") and it all just worked.