网站地链接结构,户型图装修设计图app,郑州市建设工程信息网站,m8 wordpress主题在编程的世界里#xff0c;Git 就像水一样常见#xff0c;以至于我们认为它是创建和管理代码更改的唯一可行的工具。 前 Facebook 员工#xff0c;2024 年 首先#xff0c;我为什么关心#xff1f; 我致力于构建 Graphite#xff0c;它从根本上受到 Facebook 内部工具的… 在编程的世界里Git 就像水一样常见以至于我们认为它是创建和管理代码更改的唯一可行的工具。 前 Facebook 员工2024 年 首先我为什么关心 我致力于构建 Graphite它从根本上受到 Facebook 内部工具的启发。当我开始与朋友创建一家初创公司时我从未听说过 Mercurial - 尽管我对开发工具的所有事物充满热情。我之前的工程经验包括个人项目、大学作业、Google 的 iOS 开发以及 Airbnb 的基础设施开发。在我的一生中Git 就像水一样常见。事实上它是如此常见以至于我认为它是创建和管理代码更改的唯一可行的工具。 有趣的是在 AirbnbMercurial 专家坐在离我几个座位远的地方尽管我只知道他是一个好心的同桌对他的贡献一无所知。Gregory Szorc 2021 年我的队友托马斯和尼克打开了我的思路。他们来自 Facebook令我惊讶的是他们几乎不了解 Git。相反他们接受了 Mercurial 模式和 Facebook 的“堆叠差异”工作流程的深入培训。随着时间的推移他们向我推销了非 git 工具和模式的好处最终我们做出了早期的公司转型为 GitHub 开发人员带来了堆积的差异。在此过程中我们制作了一个 CLI将 Hg 的想法融入到 Git 中。 这篇文章与我们的初创公司无关。相反这是过去三年来困扰我的根本问题。为什么 Facebook 用户Metamates ‍☠️不使用 Git 为什么要采用 Mercurial 并在其之上构建自定义工作流程 我知道 Google 不使用 Git - 但这是有道理的 - Google 的工程比 Git 早五年多。另一方面Facebook 是在 2004 年左右与 Git 创建的同时成立的当 Facebook 认真评估源代码控制工具时Git 比 Mercurial 更受欢迎。那么为什么 Facebook 不使用 Git 呢 这个问题很小众但我认为这是一个值得考虑的有趣问题。 如果 Facebook 在 2010 年代初就开始使用 Git 并做出贡献工程世界可能会有所不同。Git 可能更加用户友好并且可能本身支持堆叠更改。GitHub 可能为闭源软件开发提供了更好的支持。Uber 和 Pinterest 等前 Facebook 早期公司可能也使用 Git 和 GitHub 作为源代码控制而不是 Phabricator 和 Mercurial从而在过去十年中减少了生态系统的碎片化。 但 Facebook 并没有坚持使用 Git作为他们的主要 monorepos。相反他们采用 Mercurial 进行版本控制并在顶部逐渐添加自定义工具。为什么首先我尝试用谷歌搜索答案并找到以下明确的博客文章 https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/ 这篇十年前的文章以及后来的一些 YouTube 技术演讲给了我一个起始答案 “因为性能……” 但我想更深入地了解最初的决定工程师的意见。在队友的帮助下我在 Facebook 前成员群组上发布了一个问题询问这段历史。我还给参与该项目的两名原始工程师发送了冷电子邮件要求他们迁移到 Mercurial - 他们很友善地取消了我的记录并提供了该项目的个人帐户。以下是我了解到的 Facebook 不使用 Git 的完整原因 - 希望这篇文章可以帮助进一步记录 2024 年我们的工具为何如此的历史。 注我从未在 Facebook 工作过这个帐户是我作为一个没有在 Facebook 工作过的人对事实的最好理解。我能够与一些参与该项目的人交谈并获得他们的许可来写下他们向我解释的内容。 Facebook 为何以及如何从 Git 迁移 根据 2014 年 Facebook 博客文章Facebook 是从 Git 起步的。正如人们所预料的那样这是他们当时对源代码控制系统的默认选择。但在 2012 年左右他们开始达到规模极限。该帖子声称他们的代码库“甚至比 Linux 内核还要大很多倍Linux 内核有 1700 万行代码和 44,000 个文件”。具体来说工程师开始感觉 Git 操作很慢。虽然速度不算太慢但足够慢到值得调查。 关键瓶颈是“统计”所有文件的过程。 Git 会检查每个文件随着文件数量的增加它自然会变得越来越慢。 工程师尝试运行模拟创建一个虚拟存储库以匹配 Facebook 几年后代码库的预期规模。结果令人震惊 - 基本的 Git 命令花了超过 45 分钟才能完成。用该项目的一位原始工程师的话来说“这不是那种你想在所有工程师都抱怨之前就放弃的事情。到那时这个东西就太笨重了。尝试进行损害控制没关系想出一个更清洁的解决方案将是一项艰巨的努力。” 因此一群乌合之众的瑞典人开始研究解决方案。首先他们联系了 Git 维护者看看如何扩展 Git 以更好地支持大型 monorepos 以下是来自 Git 维护者的一封电子邮件的一些精选引述——已经过去 12 年了但读到这些消息时我还是感到有些沮丧 听起来好像你在一个 .git 中拥有所有内容。将大型存储库拆分为较小的 .git 存储库。 虽然您/可以/这样做但这不是一个好主意您应该拆分存储库 我同意。我在xx公司工作该公司拥有多年的开发历史拥有多个大型 CVS 存储库我们正在缓慢但坚定地将代码库从 CVS 迁移到 Git。把事情分开。这将使您能够更好地重新组织事情恕我直言没有任何缺点。 虽然 Git 可以更好地处理大型存储库特别是在交互式 rebase 中应用提交似乎会减慢较大存储库的速度但对于统计 130 万个文件您能做的只有这么多。 这种反应并不合作——而且在未来充满大型单一回购的情况下这种反应也没有很好地适应。Git 维护者拒绝提高性能而是建议 Facebook 对其 monorepo 进行分片。 然而分片对于 Facebook 团队来说是不可能的他们表示对 Git 不愿意扩展感到惊讶。传统上大型科技公司提供免费的开源劳动力是一件很受欢迎的礼物可以确保项目的长期寿命。 话虽这么说Git 项目没有义务屈服于 Facebook 的要求——我无意将他们描绘成这个故事中的“坏人”。仅仅因为 Facebook 的要求而做某事并不是一种生活方式。有趣的是两年后Git 维护者在看到 Facebook 为 Mercurial 做出有意义的改进后似乎改变了语气 他们邮寄了有关 git 性能问题的列表。据我所知反馈相对较少。 我有这样的印象如果他们有 git 开发社区相对不关心大型存储库的性能问题的印象我不会感到惊讶。 所以问题是 git 社区是否有兴趣在如此大规模的场景中保持竞争力 - Mercurial 现在似乎是开箱即用的 十年后Git 做出了重大改进以更好地支持 monorepos。 今天的情况已经发生了很大的变化Git 现在知道如何做到这一点在非常非常大的存储库上运行良好。 Ani Betts前 Facebook 用户 考虑的替代方案 2012 年Git 的替代品还很少。该团队考虑了闭源 PerforceGoogle 以前的源代码控制解决方案。在与 Perforce 销售工程师的早期调查电话中Facebook 指出了 Perforce 读取器和写入器节点之间的本地一致性的架构缺陷。这一回应并没有给人们带来信心——销售工程师没有意识到根本问题也没有解决该问题的路线图计划。 还考虑了其他解决方案例如 Bitkeeper但很快就被取消了资格。最后一个选择是 Mercurial。它的性能与 Git 类似但架构更简洁。Git 是一个由 Bash 和 C 代码组成的复杂网络而 Mercurial 是使用面向对象的编码模式在 Python 中设计的并且被设计为可扩展的。 其中一名调查工程师之前曾使用 Mercurial因此该团队决定参加在阿姆斯特丹举行的 Mercurial 黑客马拉松以进一步调查。 由于我之前与 Mercurial 有过很多联系因此在将 Mercurial 摆上桌面之前我竭尽全力地寻求各种可能的替代方案。 布莱恩·奥沙利文前 Facebook 员工 他们发现了一个易于扩展的系统和一个维护者社区他们非常欢迎 Facebook 团队的积极改变。 我认为这就是提到的具体黑客马拉松但我并不肯定。这段视频中展现了 2010 年初的真实氛围 https://www.youtube.com/watch?vfml4s6MEjW8 迁移整个工程组织 阿姆斯特丹黑客马拉松结束后Facebook 团队被说服了。剩下的就是让公司的其他成员相信这次迁移。这是一项令人生畏的任务 - 工程师可能对工具更改极其敏感想象一下 vim 与 emacs并且更改源代码控制系统是一件大事。 团队尽可能顺利地出发以免引发其他工程师的防御反应。接下来的事情听起来像是内部开发工具迁移的大师班。该团队花了几个月的时间宣传迁移到 Mercurial 的可能性并花时间映射 Git 和 Mercurial 之间的所有常用命令和工作流程。他们甚至收集了整个公司运行的 Git 命令的频率并专门记录了最频繁的操作在 Mercurial 中的工作方式。 其次他们为开发人员创造了表达他们的担忧并讨论新系统中可能棘手的任何边缘情况的机会。团队一开始就认为他们会因为迟钝的 8 路章鱼合并假设而陷入激烈的争论。但令他们惊讶的是他们发现同事工程师非常包容和友好。“没有人站起来并开始尖叫他们的特殊处境。” 最后他们致力于迁移并将公司移交给 Mercurial。剩下的就是历史了。Facebook 为 Mercurial 做出了性能改进使其成为大型单一存储库的最佳选择。 Evan Priestley 扩展了 Phabricator以支持 Mercurial。Facebook 利用 Mercurial 的“差异”概念创建了“堆叠”模式 解锁了新颖的代码审查并行化。前 Facebook 员工跳槽到了新公司并带来了他们的工作流程创建了一个规模虽小但声名狼藉的 diff 爱好者崇拜者。最后我遇到了其中一些爱好者并决定用我 20 多岁的时间将 Mercurial 风格的堆叠差异引入 Git 和 GitHub。 结束语 这个故事的要点是什么反思这些引述和采访我想起了经典智慧历史上许多关键技术决策都是人类驱动的而不是技术驱动的。 善良和开放在开发工具的世界中走得很远我的目标是在为源代码控制的历史做出贡献时继承这些价值观。 IT镜闻39 IT镜闻 · 目录 上一篇人工智能将意味着更多的程序员而不是更少下一篇太忙”意味着你的个人策略很糟糕