大中型开发团队如何不断将变更推送到 DVCS？
How do medium to large development teams constantly push changes to a DVCS?
我工作的公司正试图摆脱集中式 VCS StarTeam，并希望进入更好的领域。我不想只选择 SVN，因为它是 "easy option"（与我们今天所做的最相似）。谁能帮我理解一个大中型开发团队每天大约更改 150 个文件如何在 Git 或 Mercurial 这样的 DVCS 上运行？
我们有：
- 50 名开发人员在一个存储库上工作
- 15 年历史
- 15,000 个文件（主要是 code/text）
- 每天大约 150 个单个文件签到
- 由于我们独特的语言要求和数据结构，需要每天从中央提取更改
经过几天的研究和试验，我了解了 Git 和 Hg 的流程和工作流程。我不明白的是，需要快速更改（通常是单个文件）的大型团队如何能够在系统的限制下运作？
例如：我可能正在处理 3 件不同的事情，一位开发人员向我提出了一个小问题。我做了一些研究，进行必要的 1 行更改，然后签入文件。据我所知，使用 git 我需要提交更改、存储所有其他更改、拉取、推送、应用存储、处理将我的存储应用到最近提取的代码上的任何合并。有没有更好的方法？
我已经阅读了有关 Facebook 从 Git 切换到 Mercurial 的文章。他们如何在 40,000 个文件存储库中管理每天数千次签入？我无法理解它如何与 DVCS 的 pull/push 模型一起工作。这些系统的工作流程或功能一定有我遗漏的地方。也许他们不需要每天 pull/re-base？
感谢任何帮助。
I might be working on 3 different things and a developer comes up to me presenting a small issue. I do a little research, make the necessary 1 line change, and check in the file. From what I can tell, with git I would need to commit the change, stash all my other changes, pull, push, apply stash, deal with any merges applying my stash over recently pulled code might present. Is there a better way?
是的：从 Git 2.5 开始，您可以克隆一次您的存储库，但可以检查 多次 次。
如果您创建一个新分支，您可以在一个单独的工作树文件夹中创建它，而不会干扰您当前的环境。
参见“Multiple working directories with Git?”。
我希望，它会像 flame-war 来源一样迅速关闭，但是...
I don't want to just pick SVN because it's the "easy option"
请问，你是想有成效地工作还是想受苦？由于您最后（不是非常清楚）要求具有相当好的分支|合并的真实 CVCS 可能是更好的选择（参见What does SVN do better than Git? f.e.) 比伪 CVCS 模式下的任何 DVCS
After days of research and experimenting, I understand the processes and workflows of both Git and Hg.
顺便说一句，理解相当粗浅。即使在 Git 你有
- “分支”（虽然命中分支本身不是其他 DVCS 的分支）
- 可变历史
- DAG
For example: I might be working on 3 different things
与 VCS 无关的通用方式（考虑到 Mercurial，git-男孩们可能想采用它来 Git）
您创建了 3 个分支（“基于任务的开发”、“按任务创建分支”策略），每个分支都有一些（任意）数量的提交
and a developer comes up to me presenting a small issue
- “按原样”提交您当前的工作目录
- return 到您本地历史的分歧点（最后共享的变更集？）
- “做一点研究，进行必要的 1 行更改，然后签入文件”
- 开发人员拉取（您的）存储库的一部分，并将您的最后一个 chanseset 放在顶部
- 可以return回到断点继续工作
I've read the article about Facebook switching from Git to Mercurial. How do they manage thousands of check-ins a day on a 40,000 file repository? I can't fathom how that would work with the pull/push model of a DVCS. There must be something I'm missing about the workflow or functionality of these systems. Maybe they don't need to pull/re-base every day?
首先，Facebook 并没有以纯粹的 DVCS 方式使用 Mercurial。他们使用 remotefilelog extension (which they wrote themselves) to only pull changesets on demand (this works because of how Mercurial stores history so that history accesses can mostly be localized). They also use MySQL 和 memcached 作为后端服务器来提高可扩展性。
对于 rebase/merge 瓶颈（当数十名开发人员需要同时在主分支中集成他们的工作时），他们 a work in progress feature 主要在服务器端完成；我注意到这个瓶颈部分是 (1) 使用 monorepo 和 (2) 使用基于主干的开发的结果，并不是每个大型组织都会遇到这个问题。
For example: I might be working on 3 different things and a developer comes up to me presenting a small issue. I do a little research, make the necessary 1 line change, and check in the file. From what I can tell, with git I would need to commit the change, stash all my other changes, pull, push, apply stash, deal with any merges applying my stash over recently pulled code might present. Is there a better way?
您可以使用新的 Git 工作树功能（或者，对于 Mercurial，hg share）对同一存储库进行多次签出并独立处理它们。 Bazaar 和 Fossil 始终能够在本地做到这一点； Fossil 还具有以类似 SVN 的方式运行的自动同步功能（注意事项），而 Bazaar 始终能够以准集中方式工作，将提交直接发送到服务器。特别是，"only a single checkout per repository" 很大程度上是一个历史性的 Git 工件，并不代表 DVCS 系统（而且，正如我所指出的，从最近的 Git 版本开始就消失了）。
也就是说，您通常必须提交 -> 拉取 -> 合并或变基 -> 推送对主分支的更改；这是一个权衡。分布式模型允许您必须具有简单的本地版本控制，以便正在进行的工作在准备就绪之前不会直接进入主存储库。它还通常假设您的大部分工作将发生在个人分支上，因此 90% 的时间实际上只是提交（偶尔推送）。
请注意，与集中式 VCS 相比，您不会有更多或更少的冲突；它们可能只是出现在不同的点。
综上所述，如果您对当前的 VCS 感到满意并且无法确定转换的明确好处，则可能不值得更改您的 VCS。切换 VCS 会产生可衡量的成本（重建您的存储库、重新培训您的开发人员、调整工作流程、调整周围的工具、意外的过渡问题），这些成本需要被同样可衡量的收益所抵消，才能使它们物有所值。
我工作的公司正试图摆脱集中式 VCS StarTeam，并希望进入更好的领域。我不想只选择 SVN，因为它是 "easy option"（与我们今天所做的最相似）。谁能帮我理解一个大中型开发团队每天大约更改 150 个文件如何在 Git 或 Mercurial 这样的 DVCS 上运行？
我们有：
- 50 名开发人员在一个存储库上工作
- 15 年历史
- 15,000 个文件（主要是 code/text）
- 每天大约 150 个单个文件签到
- 由于我们独特的语言要求和数据结构，需要每天从中央提取更改
经过几天的研究和试验，我了解了 Git 和 Hg 的流程和工作流程。我不明白的是，需要快速更改（通常是单个文件）的大型团队如何能够在系统的限制下运作？
例如：我可能正在处理 3 件不同的事情，一位开发人员向我提出了一个小问题。我做了一些研究，进行必要的 1 行更改，然后签入文件。据我所知，使用 git 我需要提交更改、存储所有其他更改、拉取、推送、应用存储、处理将我的存储应用到最近提取的代码上的任何合并。有没有更好的方法？
我已经阅读了有关 Facebook 从 Git 切换到 Mercurial 的文章。他们如何在 40,000 个文件存储库中管理每天数千次签入？我无法理解它如何与 DVCS 的 pull/push 模型一起工作。这些系统的工作流程或功能一定有我遗漏的地方。也许他们不需要每天 pull/re-base？
感谢任何帮助。
I might be working on 3 different things and a developer comes up to me presenting a small issue. I do a little research, make the necessary 1 line change, and check in the file. From what I can tell, with git I would need to commit the change, stash all my other changes, pull, push, apply stash, deal with any merges applying my stash over recently pulled code might present. Is there a better way?
是的：从 Git 2.5 开始，您可以克隆一次您的存储库，但可以检查 多次 次。
如果您创建一个新分支，您可以在一个单独的工作树文件夹中创建它，而不会干扰您当前的环境。
参见“Multiple working directories with Git?”。
我希望，它会像 flame-war 来源一样迅速关闭，但是...
I don't want to just pick SVN because it's the "easy option"
请问，你是想有成效地工作还是想受苦？由于您最后（不是非常清楚）要求具有相当好的分支|合并的真实 CVCS 可能是更好的选择（参见What does SVN do better than Git? f.e.) 比伪 CVCS 模式下的任何 DVCS
After days of research and experimenting, I understand the processes and workflows of both Git and Hg.
顺便说一句，理解相当粗浅。即使在 Git 你有
- “分支”（虽然命中分支本身不是其他 DVCS 的分支）
- 可变历史
- DAG
For example: I might be working on 3 different things
与 VCS 无关的通用方式（考虑到 Mercurial，git-男孩们可能想采用它来 Git）
您创建了 3 个分支（“基于任务的开发”、“按任务创建分支”策略），每个分支都有一些（任意）数量的提交
and a developer comes up to me presenting a small issue
- “按原样”提交您当前的工作目录
- return 到您本地历史的分歧点（最后共享的变更集？）
- “做一点研究，进行必要的 1 行更改，然后签入文件”
- 开发人员拉取（您的）存储库的一部分，并将您的最后一个 chanseset 放在顶部
- 可以return回到断点继续工作
I've read the article about Facebook switching from Git to Mercurial. How do they manage thousands of check-ins a day on a 40,000 file repository? I can't fathom how that would work with the pull/push model of a DVCS. There must be something I'm missing about the workflow or functionality of these systems. Maybe they don't need to pull/re-base every day?
首先，Facebook 并没有以纯粹的 DVCS 方式使用 Mercurial。他们使用 remotefilelog extension (which they wrote themselves) to only pull changesets on demand (this works because of how Mercurial stores history so that history accesses can mostly be localized). They also use MySQL 和 memcached 作为后端服务器来提高可扩展性。
对于 rebase/merge 瓶颈（当数十名开发人员需要同时在主分支中集成他们的工作时），他们 a work in progress feature 主要在服务器端完成；我注意到这个瓶颈部分是 (1) 使用 monorepo 和 (2) 使用基于主干的开发的结果，并不是每个大型组织都会遇到这个问题。
For example: I might be working on 3 different things and a developer comes up to me presenting a small issue. I do a little research, make the necessary 1 line change, and check in the file. From what I can tell, with git I would need to commit the change, stash all my other changes, pull, push, apply stash, deal with any merges applying my stash over recently pulled code might present. Is there a better way?
您可以使用新的 Git 工作树功能（或者，对于 Mercurial，hg share）对同一存储库进行多次签出并独立处理它们。 Bazaar 和 Fossil 始终能够在本地做到这一点； Fossil 还具有以类似 SVN 的方式运行的自动同步功能（注意事项），而 Bazaar 始终能够以准集中方式工作，将提交直接发送到服务器。特别是，"only a single checkout per repository" 很大程度上是一个历史性的 Git 工件，并不代表 DVCS 系统（而且，正如我所指出的，从最近的 Git 版本开始就消失了）。
也就是说，您通常必须提交 -> 拉取 -> 合并或变基 -> 推送对主分支的更改；这是一个权衡。分布式模型允许您必须具有简单的本地版本控制，以便正在进行的工作在准备就绪之前不会直接进入主存储库。它还通常假设您的大部分工作将发生在个人分支上，因此 90% 的时间实际上只是提交（偶尔推送）。
请注意，与集中式 VCS 相比，您不会有更多或更少的冲突；它们可能只是出现在不同的点。
综上所述，如果您对当前的 VCS 感到满意并且无法确定转换的明确好处，则可能不值得更改您的 VCS。切换 VCS 会产生可衡量的成本（重建您的存储库、重新培训您的开发人员、调整工作流程、调整周围的工具、意外的过渡问题），这些成本需要被同样可衡量的收益所抵消，才能使它们物有所值。