【外评】”GitHub “开始让人感觉像传统软件
多年来，我使用过很多工具，这意味着我看到很多工具都陷入了瓶颈。这并不总是一个问题；有时，一些东西刚刚 “完成”，不需要任何改变。不过，这往往预示着即将发生的事情。时不时地，有些东西会从低谷中走出来，重新开始进步，但这往往是长期衰退的早期征兆。我并不总能分辨出一件事是在平稳发展，还是真的开始恶化；这很容易成为煮熟的青蛙。当一些对我来说非常重要的东西出现问题时，我的情况就会发生变化。
对我来说，GitHub 的 “杀手级 “强大用户功能之一就是它的blame视图。命令行上的 git blame很有用，但很难阅读；它不是我每天都会使用的界面。GitHub 的网页用户界面不仅方便，还能让我轻松逐行点击查看旧版本的blame视图，功能强大得无与伦比。这是让我对产品情有独钟的功能之一： 我不再使用离线图形化的 git 客户端，就是因为它比以前好用多了。
不过有一天，我试图在一个大文件上使用 “blame “视图，结果遇到了一个我不记得以前见过的问题： 我就是找不到我要搜索的那行代码。我在浏览器的命令+F 搜索框中输入了该行的各种关键字，但什么也没找到。我一筹莫展，直到过了一会儿，我一边闲逛页面，一边再次进行搜索，终于找到了我要找的那行代码。我意识到一定发生了什么。
我听说 GitHub 正在用 React 进行前端重写，我意识到一定是这个原因。问题并不是我想要的那行内容不在页面上，而是整个文档没有被一次性呈现，所以我的浏览器内置搜索栏无法找到它。凭直觉，我试着在浏览器中完全禁用 JavaScript，结果它突然又开始工作了。GitHub 能够发送完全服务器端渲染的页面版本，这实际上是应该的，但除非 JavaScript 完全不可用，否则不会发送。
我并不反对 JavaScript，也不反对 React。只要用对了地方，任何工具都完全没问题。问题是：这个地方并不合适，对我个人来说是关键的功能，突然之间就不能一直正常工作了。这并不是 GitHub 在过去几年中唯一让人感觉微妙恶化的功能–曾经业界领先的状态页面不再及时报告可用性方面的小问题；操作运行时会随机中断与 GitHub 自身 API 的网络连接；点击合并按钮有时会将页面滚动到错误的位置–但这是第一次让我真正意识到，GitHub 今后可能不会再好起来了。
公司的品牌、新的 “人工智能驱动的开发者平台 “口号都清楚地表明，我心目中的 “GitHub”–传统的网站、对我而言的核心功能–根本就不是微软目前的优先考虑事项。我知道 GitHub 有很多有才华的人，他们很关心 GitHub，但该公司的优先事项似乎并不重视我所看重的服务。这并不是一个反人工智能的声明，而是认识到我每天仍需要使用的工具已经过了它的黄金时期。Copilot 并没有为我导航网站，取代我对网站的需求。我曾经使用过一些工具，它们也曾走过这样的衰退期，但我并不乐观。它现在仍然很好用，也许在未来几年也会如此，但我想知道我现在还有什么其他选择，而不是等到情况比现在更糟的时候。
同时……我仍然需要每天使用 GitHub，但也许是时候开始探索新的平台了–找到一个能像 GitHub 网页界面一样好用的本地blame工具。(有喜欢的工具，请发送到 misty@digipres.club / @cdrom.ca。）
本文文字及图片出自 "GitHub" Is Starting to Feel Like Legacy Software
你也许感兴趣的：
- GitHub 删除代码等于“任何人均可永久访问”！微软回应：我们有意为之
- 编码20年，现在的我想放弃GitHub！
- GitHub 变 Twitter？强“喂”新推荐算法引公愤，开发者从“编程乌托邦”被驱赶到了信息茧房
- 让部署更快更安全，GitHub 无密码部署现已上线
- 开发者危机！微软GitHub启动裁员：印度工程师团队几乎整体裁撤
- 因使用 GitHub ，我们被取消了参赛资格
- 告别SVN，Git成“独苗”：GitHub 在 13 年后宣布淘汰Subversion支持
- GitHub被起诉，版权问题再引热议，网友类比谷歌图书：毕竟谷歌没拿用户内容写小说
- GitHub 前 CTO：全面微服务是最大的架构错误！网友：这不是刚改完 GitHub 吗
- “放弃 GitHub ，时机已到”，软件自由保护协会怒批！
有一些可靠的工具真的很不错，你只需学习一次，就能持续使用十年，从而腾出时间来掌握工作的其他部分。(就像本周流行的 CSS in JS）。
Visual Studio Code 似乎也是如此。当然，他们有一个很大的更新日志，但实际的使用体验感觉与刚发布时非常相似。
> 拥有可靠的工具真的很好，你只需学习一次，就能持续使用十年，从而腾出时间来掌握工作的其他部分。
我非常同意你的观点，但奇怪的是，我遇到了很多持相反观点的人。在这个行业里，有无穷无尽的有趣和/或有用的东西需要学习；花时间重新学习如何在一个我已经用了十年的应用程序中完成一项平凡的任务是一种浪费。
我同意，我希望 GitHub 能继续成为这样一个平台，而不是像 ms 现在这样。
开发者，开发者，开发者！
我也想念鲍尔默
还是你想念可卡因？
我也想念可卡因
这正是帖子作者想要的，但显然微软正在破坏 Github。
我相信 Github 在未来十年内还会继续存在，但我不确定它是否还会成为每个人托管源代码的默认位置。这真是个遗憾。
可惜？不是 请把网络效应转移到一个不属于微软及其低劣人工智能企业的平台上，这样我的代码才能跟上，看在上帝的份上，快点！
GitHub 真正的遗产是代码审查流程，这可能是企业客户使用最多的表面领域之一。
操作和代码空间（Codespaces）已经带来了巨大的变革，但代码审查等核心功能却没有得到同样程度的改进，实在令人失望。
Phabricator 近十年前就具备的基本功能现在仍然缺失： – 高亮显示复制/移动的代码块–代码覆盖率的沟槽指示器–堆叠差异–默认情况下不折叠大的变更（多么可笑的默认设置！”这里有很多代码发生了变化，这意味着这里很可能有 bug – 我会为您隐藏这些代码，让您的审核更轻松！”）。
我不记得 Phabricator 对它的支持有多好了，但通过携带注释和显示不同版本之间与之前 PR 版本的差异来理智地处理 rebases 将是非常棒的。我不得不在 GitHub 中重新审核整个 PR 的次数可想而知，因为如果作者重新创建了自己的分支，GitHub 就无法显示自上次审核以来发生了哪些变化……
公平地说，在过去十年中，他们确实改进了公关流程中的一些事情，但肯定还有很多事情可以做。我只希望他们的 API 团队能保持充足的资源，这样 Graphite 和 Reviewable 这样的代码审查工具才能继续发挥作用！(免责声明：我是 Reviewable 的创始人）。
他们至少可以支持使用快进合并的拉取请求。
参见：https://github.com/orgs/community/discussions/4618
GitHub 目前最重要的产品可能是 API。它的功能非常全面，因此很容易用工具来增强或替换体验的任何部分。
因此，许多拥有私有仓库的团队只使用 GitHub 进行基础工作（版本控制、访问管理），然后使用第三方兼容工具进行其他工作。Linear 用于处理问题，Buildkite 用于 CI，Graphite 用于代码审查，等等。
通过 API，我创建了 CodeApprove（codeapprove.com），这是我一直希望 GitHub 拥有的代码审查界面。与我有同样偏好的团队可以自选使用它，而不会失去 GitHub 坚如磐石的基础。
我知道，我们都被锁定在这个由一家并不总是友好的大公司所拥有的平台上并不是件好事，但它至少是个不错的平台。
我同意他们的 API 是最重要的，但在我看来，他们在这方面做得并不是特别好。你有两个独立的 API 系统（REST 和 GraphQL），它们相互重叠，但都不是对方的超集；有两个独立的 ID 系统；在处理现场旧 GHE 实例使用的各种不兼容 API 版本时没有任何帮助；OAuth 应用程序与应用程序在允许调用的 API 上有不同的限制，它们之间没有明确的迁移路径；他们自己的用户界面使用的重要功能完全不能通过 API 使用；一个复杂的 API 配额系统，等等。
坦率地说，很多地方给人的感觉就像他们试图用闪闪发光的新东西淘汰并取代旧系统，但中途却意识到他们做不到，现在我们只能在可预见的未来使用两个有点不兼容的系统。在这方面，他们真的需要一个强有力的技术领导。
PAT 也有这种感觉，尽管被推到了新的 PAT 中，但我用到的大多数东西仍然需要传统的 PAT。而且文档也很糟糕。我也有同样的想法，PAT 过渡和 API 过渡给人的感觉就像一个未完成的功能。
对我来说，API 的过渡更加奇怪，因为用 GraphQL 封装 REST 调用几乎是小菜一碟。
在我看来，GitHub 的技术欠账越来越严重，却没有得到解决，如果这还不能说明 GitHub 这样的产品出现了问题，那我就不知道还有什么能说明问题了。
文章中的抱怨是合理的，而且听起来完全有可能是因为重写了 React，因为作为性能优化，避免渲染屏幕外的内容是 React 中相当标准的做法。
但这其实是重写的管理问题，与技术无关。github 上有人决定不呈现屏幕外内容。这与之前的工作方式相比打破了人们的预期，这就是为什么感觉应用程序在走下坡路。
更重要的一点是，如果有人要重写，并试图与现有的用户体验相匹配……这需要更深层次的匹配，而不仅仅是将像素放在正确的位置。
这是因为负责这项技术的人不知道人们想如何使用这项技术。
这意味着你可以期待它继续走下坡路，直到有更高的人采取行动。
我经常听到这种观点（尤其是在 Twitter 上），但我完全不同意。我认为 Github 仍然是一款了不起的软件，而且微软对它的投资几乎超过了最近从任何母公司收购的任何项目。
对于一个在非常复杂的软件中突然出现的 bug，这感觉就像一个非常戏剧化的框架。
但这并不是一个错误。就像现在的许多网站一样，为了节省客户端浏览器的带宽和资源，它们在导航时不会加载整个页面，这是一种有意的设计选择。
我以前也被这个问题困扰过。在查看一个拉取请求的文件选项卡时，我按下 ctrl-f，开始键入一个我知道是 PR 一部分的文件名，结果……什么都没有。找不到。找不到。
直到我向下滚动了一点，页面上的 JS 才加载了更多的差异，然后我要找的文件就出现在了列表中，点击后就可以滚动到该文件。
这种懒加载方式可以节省客户端和服务器的系统资源，但却降低了可用性。
这种模式太令人沮丧了–尤其是当他们在页面中捕获查找热键，但直到 js 完全加载后才捕获热键时。这让我不禁要问，将浏览器查找事件暴露给页面是否会有所帮助–通过确保整个 dom 已加载并可搜索来处理查找事件。
> 这可能是为了节省客户端浏览器的带宽和资源而故意做出的设计选择。
完整的源文件可能只是 React 垃圾文件的一小部分。
与其说他们是在通过虚拟视图限制 DOM 的大小，不如说是在限制下载的大小。不幸的是，HTML 虚拟视图会破坏页面中查找等功能。
我觉得 “Github 仍然是一款了不起的软件 “和 “GitHub 有一些恼人的 bug，实在不该有 “这两种观点其实并不冲突，它们可以同时成立。
我之所以使用 GitHub，是因为它仍然是最好的选择，而且还有相当大的优势。[1] 但我也认为它有一些愚蠢的 bug（有时要花很长时间才能修复）、一些错误的设计，有时甚至是完全错误的功能。
例如，如果你使用浅色方案，GitHub 的操作日志就会显示为对比度相当低的深色。这对我来说非常难以阅读；我使用浅色主题是有原因的。所以我需要打开 “原始日志”，然后从那里查看。这可行吗？可以。我是否非常讨厌使用 GitHub Actions，因为它的工作流程实在太烦人了？是的。
GitHub 讨论几乎毫无用处。试着在一个较大的线程上发表评论，你会很难找到自己的评论，也很难看到是否有人回复。制作一个比 Twitter 更混乱、更糟糕的对话用户界面是一项相当大的成就，但 GitHub 却做到了。
其中有些功能令人费解；这些都不是新功能，而且很容易上手。就像 “后退 “按钮的功能在半年或更长的时间里都无法正常使用，直到他们最终修复了它。
[1]: 我已经有一段时间没有评估 Gogs/gitea/Forgejo 了。另外，整个双叉的事情也有点令人遗憾。
100%同意。
这绝对是一个了不起的平台。
事实上，令人惊讶的是，即使在收购和压倒性采用之后，它仍然保持着高质量。我预计范围蠕变会无限制地增长。
我还记得 Jira 推出这种完全相同的文本渲染回归时的情形。我们工作时使用的看板上几乎没有人，通常只有不到 20 张票据。我点击 ctrl+f 跳转到我想要的票单编号，结果……什么都没有。浏览器找不到它！原来，票单略低于视图端口，而同时呈现 20 张票单对于现代票单网络应用来说显然是太多了。
现代框架中的倒退数量有时令人咋舌。就我个人而言，在一个资源充足的项目中处理如此基本的任务都会让我感到尴尬，但我相信引入这种回归的重新设计是使用了各种在简历上看起来很不错的流行框架和模式。
我觉得ctrl/cmd f在整个网络中都受到了很大的冲击。它曾经是一个非常可靠的工具，能让你最快到达你想去的地方。
GitHub 的 Web UI 要改用 react 了？可悲的是，Rails 提供了使用 websockets（如 Elixir Liveview）提供异步更新视图的方法。在发现尽可能多地使用 Rails 更易于维护后，我几乎放弃了 Vue。不仅是我自己，整个团队都能通过这种方式加快工作进度。后端人员通常对前端有足够的了解，但可能并不了解 Vue/React 的深奥之处，因此在分配简单任务时会造成延误。再加上大量重复的逻辑（权限、模型等）。
你需要一些相当严重的 “桌面风格”（讨厌这个词）用户界面复杂性来要求 React，而我并不完全明白 GitHub 需要的是什么。
也许他们想把 GitHub 变成浏览器中的 VSCode？
> 也许他们想让 GitHub 像浏览器中的 VSCode 一样？
已经可以了。在任何版本库中按下”. “键，就能在浏览器中用 VS Code 打开版本库。
在微软接管之前，GitHub 在相当长的几年里一直停滞不前。还记得因为会复制行号而无法有意义地复制代码吗？花了那么长的时间才解决，有点可笑。但最近几年……是的，我觉得它变得越来越烦人了。我有时真的怀疑，GitHub 的工作人员自己是否真的在使用它。
我曾试着向 GitHub 报告一些非常明显且恼人的 bug，但它们甚至从未被修复，或者花了几个月才被修复，或者修复后过了一段时间又坏了。我也就不再理会了。
GitLab 还是比 GitHub 差很多。
至于 React，不幸的是，有一部分前端开发者似乎认为所有东西都必须使用 React，React 是唯一可能的答案，而所有不使用 React 的人都是腐朽的开发者，可能是腐朽的人，也很可能是注册过的无名小卒，他们通常会永远大谈 React，直到全世界都改用 React。你的前端将被同化。
React 并不是唯一存在这种问题的技术，但它可能是最令人沮丧的技术之一，因为作为用户，我并不关心你使用的是什么语言或数据库，因为我通常并不真正接触这些语言或数据库，但我确实直接接触了你的前端。
TIL React 开发人员是 GNOME 开发人员
别再做这些零努力零内容的离题刷屏了。这里明确规定不允许这样做。
请不要这么说！
他们会去 “现代化 “它，让它成为一个速度慢 10 倍、更加臃肿的讨厌的网络用户界面，并为了它而移动所有按钮和 URL。
这在某种程度上已经发生了。Repo 文件和侧边栏都是客户端加载的，速度很慢。
我认为，文章中阐述的许多问题都是 GitHub 最近 “现代化 “转向 React 的结果。
这篇文章正是在抱怨 “现代化”。
它现在是一个 rails 应用程序，所以如果有其他东西会变慢，我会很惊讶的，lol。除非他们真的搞砸了重写什么的，但从技术角度来说，几乎任何其他东西都会更快。
你可能需要仔细读一下这篇文章： 它抱怨的正是这一点。
> 并找到一个能像 GitHub 网页界面一样好用的本地责备工具
我不知道你到底想要什么，但如果你想更好地查看 git blame、git show、git diff 等，我建议你用 delta。Delta 可以格式化这些 git 命令的输出，让你以更漂亮的方式查看它们的输出。你还可以用它来替代人类可读的 diff。更多信息：https://dandavison.github.io/delta/
不过，尽管 git blame（及其图形界面）是一款快速简便的工具，但它也存在一些问题，而 Git 有更好的代码考古工具。更多信息请参见：https://news.ycombinator.com/item?id=39877637
此外，如果你是 Emacs 用户，它的 VC 软件包也非常强大。例如，”C-x v g “可以调出 “责备”（vc-annotate）视图，你可以（对任何提交）按 “a “查看提交前文件的样子，按 “d “查看提交的差异，按 “l “查看提交信息……。这只是冰山一角。它的后台支持 Git、Mercurial、Bazaar、CVS、Subversion 等。
https://www.emacswiki.org/emacs/VersionControl
我曾使用 GitHub 多年（2009-2014 年），后来被一家大型科技公司收购了 8 年，因此没怎么用过它，后来又回到一家使用它的初创公司，感觉它就像一个完全不同的产品。从这个角度看，这是一个截然不同的产品。
GitHub Actions 是其中重要的一部分。Codespaces 是 Mac CI 的解决方案，可以自动执行大量工作、存储秘密、从 GitHub 直接驱动 CI 和 CD 等。它的发展可谓一日千里。此外，公司还在通过 copilot 和 vscode（以及以前的 atom）做其他事情。
当然，代码搜索只是略有改善，也许 Git 的某些核心功能在用户界面上没有那么炫目，但它已经有了长足的进步。
代码搜索是我最希望看到改进的一点。
只要雇一个曾在谷歌工作过的人，复制他们的内部代码搜索就可以了。
(预览：https://source.chromium.org/）
技术注意事项：为了有效工作，它需要能够编译代码（将代码解析为 AST），这对许多 GitHub 项目来说具有挑战性。不过我敢打赌，他们可以轻松达到 80% 的编译率，然后使用哑文本搜索来处理其余部分。
出于某些原因，禁用 JavaScript 并不总是对所有文件都有效；我也不知道为什么。有些文件即使禁用了 JavaScript 也能显示，但有些文件却无法显示。有些文件在禁用 JavaScripts 后只能部分运行。
不过，即使不起作用，服务器也会把 JSON 作为 HTML 文件的一部分发送，其中包含所有相关数据，所以我自己写了一个脚本，它比 GitHub 中的脚本短得多，速度也快得多，还能避免下载脚本时需要额外请求。
此外，它还支持 git 协议，因此仍然可以使用，而且还有 API。幸运的是，它有很好的文档，而且在没有 JavaScripts 的情况下也能工作（文档应始终在没有 JavaScripts 的情况下工作；如果您的网站有文档，但在没有 JavaScripts 的情况下无法工作，请纠正这一点，即使其他文件在没有 JavaScripts 的情况下无法工作是有正当理由的（这种情况并不常见，因为通常是没有正当理由的））。
尽管如此，他们必须这样做并不是很好，他们应该让设计工作不至于如此混乱。(他们在这篇文章中描述的方式，确实存在那里描述的问题和更多问题；这是因为 WWW 的杂乱无章，但他们可以避免使用许多较新的东西，使其更加兼容，提高可访问性，并避免许多需要添加考虑的问题，而如果设计得当，这些考虑甚至是不必要的（因为这样客户端就能够根据用户的偏好自动处理，而不需要服务器告知）。
能分享一下你的脚本吗？
我觉得 GitHub 大体上还不错。
但代码审查是个例外，这可以说是它最重要的用例。一旦有了一些来来回回的修改，再经过几轮修改，就很难找到评论列表了。也许是我遗漏了某个地方，但在对话选项卡中散布是不可能找到的。
我用了几个脚本，把所有的线程拉到一个我可以用 vim 打开的文件里。然后我就有了跳转到代码中相应位置的快捷方式。效果不错，但似乎真的没有必要。
> 感觉像遗留软件
鉴于他们的博客设计让人联想到 24 年前 OS X 的 “金属拉丝 “主题，这样说有点讽刺意味
https://en.m.wikipedia.org/wiki/Aqua_(user_interface)#/media…
很多老软件都比现代软件更好用。
用户体验不仅仅是视觉上的美观，同样重要（或更重要）的是它的行为方式、用户与它的交互方式，以及它如何摆脱你的束缚，让你完成实际工作（或不完成工作）。
我不反对。
但作者的意思是 “传统=糟糕”。
注：我真心喜欢 Windows 2000 的用户界面/用户体验（并希望它今天仍然存在）
我认为这是一个完美的小细节，它捕捉到了这位作者的个性。他们的博客使用的是曾经非常著名和流行的 Octopress [0]。每个开发人员都在用它运行自己的博客。
我想说的是，看起来作者找到了一个十多年来一直行之有效的东西。他们希望 GitHub 能 “正常工作
0: http://octopress.org/
我觉得这个设计没那么老。早在 11 年前，我就从事网页设计工作了，当时很多设计理念都很 “流行”。微妙的明暗 1px 线条营造出嵌入式效果，某些元素周围有一些阴影，而不是完全琐碎的排版。这是 2010-2014 年的设计类型。
这个博客使用的是不支持的软件（Octopress）。我认为它自 2016 年以来就没有更新过。
不久前，我开始尝试构建一个本地优先的 GitHub 客户端：https://github.com/tinyplex/tinyhub
看起来，GitHub 的界面更像是一个 “应用程序”，而不是一个 “网站”。是我的错觉？
> 还是只有我？
我只是一个数据集，但我不同意。在这一点上，Github 这个网站已经运行了十多年，效果相当不错。正如帖子作者所说，最近才开始出现一些裂缝。
它的主要用途是浏览文档。
这并不是说它不是一个应用程序，而是说它的许多目标应该与浏览器类似。
这种感觉，再加上它们缺乏堆叠支持，促使托马斯、梅里尔和我在 graphite.dev 上黑了好几年。
最近有一次，我试图理解 “为什么开发人员会在我使用的应用程序中创建这样的界面”，这时我意识到，我看到的基本上是一个 “React 类型的界面”，而这并不适合，”为什么 “也许是因为年轻的开发人员习惯于看到/实现这样的东西，所以他们可能根本意识不到这是一种糟糕的方法。
我希望所有的软件都能像传统软件一样。
听起来其实是个 bug。在我编写的应用程序中，如果有人报告了类似的问题，我就会把它视为 “错误”，并设法解决。
> 我看到很多工具都陷入了瓶颈。
我认为这是开发平台的理想状态。不断调整可能会导致很大的问题（听起来就像这里发生的情况）。我曾在 Xcode 上放过一个大屁。
GitHub 的通知是最糟糕的。完全没用；不，是令人愤怒。这是他们首先应该改进的地方。
虽然我理解在差异文件中折叠大文件的动机，因为你想保持较低的 DOM 元素数量，但拜托……你真的不能把 PR 中的大部分改动隐藏起来。至少让折叠文件更突出一些，这样你在审阅时就不会错过它们了。或者，我猜你是不想让我扩充它们，或者你无缘无故地做了那么多折叠工作。那么重点又是什么呢？
10 年前就提出了机关准则，但至今仍未落实。看起来很简单……
我觉得这篇文章的关注点太狭隘了。Github 要解决的问题多种多样，受众也各不相同。人们使用 Github 和 Git 的方式完全不同，因此存在空格键加热问题。他们的 “责备 “视图，也就是这篇文章一半的内容，我很少用过。同样，有些团队会在代码审查期间重定向，有些则在审查之外处理，等等等等。
至于 Ctrl+F 的问题，我认为使用语法高亮渲染巨型文件会降低旧电脑的性能，而且他们正试图为使用 Github（网络版–请记住）的用户解决这个问题，因为如果你需要完全的可搜索性，你可能会在本地克隆 repo。
我不知道，也许 Github 在幕后把一切都搞砸了，但在我看来，这篇文章并没有提出令人信服的论据。
我已经很久没有看到 octopress 网站了。我怀念octopress，怀念与之相伴的个人网站写作文化。基于最大写作速度和效率的共享模板。
有人知道 Git 的客户端责备前端吗？我以前用的是 Git Extensions 的那个，但不知从什么时候开始，它就不能用了。
如果可以选择 TUI，那么 “tig blame “是个不错的界面。
https://github.com/jonas/tig
“git gui blame “也不错，而且 git 自带了 git-gui。
> 但不知从什么时候开始，它就不再为我工作了。
我更新了 Git 和 Git 扩展，似乎解决了这个问题，但我遇到的问题都是零星的，也许是我运气好吧。
JetBrains 集成开发环境中的那个很不错。”注释以前的修订 “非常有助于及时回顾。
我想大多数现代集成开发环境和文本编辑器都至少有一个。我记得的有
– JetBrains 的 Annotate
– VSCode 的 GitLens
– Emacs 的 Magit
Tortoisegit?
> 问题不在于我想要的那一行不在页面上，而在于整个文档没有被同时渲染，所以我的浏览器内置搜索栏无法找到它。
Ctrl/Cmd-F 在责备/代码页面上会被拦截，并打开一个自定义的查找用户界面，老实说，我觉得这样很好。浏览器的 “页面内查找 “功能并不是用来搜索代码的，而且速度很慢。
也许 GitHub 正在改用 React（我对此一无所知），但 React 并不强制或甚至原生支持删减屏幕外的内容，所以我不确定这其中有什么联系。
我讨厌现在的内容渲染效率如此之低，以至于无法一次性渲染整个文档，从而破坏了浏览器内置的搜索功能。这感觉就像是现代软件的倒退。
Slack 就是这样做的，我非常讨厌。在长线程中搜索关键词是不可能的。原生应用会直接劫持搜索功能，即使在浏览器上打开也不行，因为它只会渲染屏幕上的部分。我相信有人在实现这个功能时一定觉得自己很聪明。
如今，考虑到如此多的网站都是网络应用而非网页，网络确实值得被视为操作系统或应用平台。
如果有一个既定的工具，可以上下滚动屏幕上无法显示的文档就好了
等待
> 所以我不知道这其中有什么联系。
我不认为他们会特别指责反应。更多的是，对他们来说，当他们想起阅读前端是用 react 重写的时候，才恍然大悟，这可能是重写造成的。
我越来越反感 react 了。我每天都要处理 UI 滞后问题，而且每天都要处理很多次，这让我非常恼火。我已经厌倦了从手指开始移动到鼠标点击或手指点击触摸屏时按钮移动的过程，因为一个模块比其他模块晚加载十秒钟。
要想获得指责视图，OpenGrok 有一个 “注释 “功能。
是的，我不太喜欢 GitHub（尤其是在微软收购之后），但我也讨厌那种 “我们需要发展”、”我们需要扩张 “的愚蠢态度。有时候，工具已经做好了，能改进的地方实在不多。尤其是从用户界面的角度来看。如果你开始强行改进，通常会导致设计过度，使用起来很痛苦。
并不是说传统的东西就一定不好或应该避免。事实上，大多数情况下是相反的。这意味着它很稳定，能帮助你完成工作。在我看来，传统与进步之间的平衡并不那么明显。
老实说，我不知道这个博客是不是在耍流氓，但这里的评论表明他们不是。
难道只有我一个人满足于在终端运行 `git blame`，使用 `less` 作为寻呼机，然后按 `/` 进行搜索吗？
GitHub 正在慢慢将社交功能置于开发者工具和体验之上。现在关注 GitHub Stars 的开发者数量有点令人担忧。我觉得每周至少都能在 HN 上看到一篇帖子，询问如何提高 GitHub 仓库的星级。
它们显然可以像其他平台上的指标一样被购买。
有人用它们来骗人，他们克隆一个合法项目，添加一个后门，然后购买星级并进行搜索引擎优化，让人们克隆这个糟糕的 repo。
Gitlab 比 Github 快多了。
Gitlab 在很多方面确实比 Github 好（除了设置菜单的老鼠窝）。
举例来说，如果你合并了一堆分支中的中间分支，gitlab 会重定向更高的分支。而 Github 只会让它们成为孤儿。
有意思。我上一次使用 gitlab 是在 2021-22 年，主观上感觉它们不相上下。你有任何基准或其他来源吗？
有啊。这是一个大屁股的古董 rails 应用程序，试图用 turbolinks 来提高速度。
Rails 应用程序不是问题。问题在于一大堆与协作或代码版本管理无关的噪音和功能。
我自己也喜欢 Rails，并不是说它不好。不过，可能早就该有类似 SPA 的体验了。很多用户界面都太过时了。事实上，公关中最基本的东西都被隐藏在披露菜单下面，而如果没有菜单，就有足够的空间将其置于线内，这让人很沮丧。比如编辑 PR 的描述就需要点击两次，而点击一次就可以了。一切都让人感觉是临时拼凑的。比如将 PR 标记为草稿……我第一次就花了很长时间才找到。
产品设计的质量与这些内容如何到达你的浏览器之间没有任何关联。
有一些可靠的工具真的很不错，你只需学习一次，就能持续使用十年，从而腾出时间来掌握工作的其他部分。(就像本周流行的 CSS in JS）。
Visual Studio Code 似乎也是如此。当然，他们有一个很大的更新日志，但实际的使用体验感觉与刚发布时非常相似。
> 拥有可靠的工具真的很好，你只需学习一次，就能持续使用十年，从而腾出时间来掌握工作的其他部分。
我非常同意你的观点，但奇怪的是，我遇到了很多持相反观点的人。在这个行业里，有无穷无尽的有趣和/或有用的东西需要学习；花时间重新学习如何在一个我已经用了十年的应用程序中完成一项平凡的任务是一种浪费。
我同意，我希望 GitHub 能继续成为这样一个平台，而不是像 ms 现在这样。
开发者，开发者，开发者！
我也想念鲍尔默
还是你想念可卡因？
我也想念可卡因
这正是帖子作者想要的，但显然微软正在破坏 Github。
我相信 Github 在未来十年内还会继续存在，但我不确定它是否还会成为每个人托管源代码的默认位置。这真是个遗憾。
可惜？不是 请把网络效应转移到一个不属于微软及其低劣人工智能企业的平台上，这样我的代码才能跟上，看在上帝的份上，快点！
GitHub 真正的遗产是代码审查流程，这可能是企业客户使用最多的表面领域之一。
操作和代码空间（Codespaces）已经带来了巨大的变革，但代码审查等核心功能却没有得到同样程度的改进，实在令人失望。
Phabricator 近十年前就具备的基本功能现在仍然缺失： – 高亮显示复制/移动的代码块–代码覆盖率的沟槽指示器–堆叠差异–默认情况下不折叠大的变更（多么可笑的默认设置！”这里有很多代码发生了变化，这意味着这里很可能有 bug – 我会为您隐藏这些代码，让您的审核更轻松！”）。
我不记得 Phabricator 对它的支持有多好了，但通过携带注释和显示不同版本之间与之前 PR 版本的差异来理智地处理 rebases 将是非常棒的。我不得不在 GitHub 中重新审核整个 PR 的次数可想而知，因为如果作者重新创建了自己的分支，GitHub 就无法显示自上次审核以来发生了哪些变化……
公平地说，在过去十年中，他们确实改进了公关流程中的一些事情，但肯定还有很多事情可以做。我只希望他们的 API 团队能保持充足的资源，这样 Graphite 和 Reviewable 这样的代码审查工具才能继续发挥作用！(免责声明：我是 Reviewable 的创始人）。
他们至少可以支持使用快进合并的拉取请求。
参见：https://github.com/orgs/community/discussions/4618
GitHub 目前最重要的产品可能是 API。它的功能非常全面，因此很容易用工具来增强或替换体验的任何部分。
因此，许多拥有私有仓库的团队只使用 GitHub 进行基础工作（版本控制、访问管理），然后使用第三方兼容工具进行其他工作。Linear 用于处理问题，Buildkite 用于 CI，Graphite 用于代码审查，等等。
通过 API，我创建了 CodeApprove（codeapprove.com），这是我一直希望 GitHub 拥有的代码审查界面。与我有同样偏好的团队可以自选使用它，而不会失去 GitHub 坚如磐石的基础。
我知道，我们都被锁定在这个由一家并不总是友好的大公司所拥有的平台上并不是件好事，但它至少是个不错的平台。
我同意他们的 API 是最重要的，但在我看来，他们在这方面做得并不是特别好。你有两个独立的 API 系统（REST 和 GraphQL），它们相互重叠，但都不是对方的超集；有两个独立的 ID 系统；在处理现场旧 GHE 实例使用的各种不兼容 API 版本时没有任何帮助；OAuth 应用程序与应用程序在允许调用的 API 上有不同的限制，它们之间没有明确的迁移路径；他们自己的用户界面使用的重要功能完全不能通过 API 使用；一个复杂的 API 配额系统，等等。
坦率地说，很多地方给人的感觉就像他们试图用闪闪发光的新东西淘汰并取代旧系统，但中途却意识到他们做不到，现在我们只能在可预见的未来使用两个有点不兼容的系统。在这方面，他们真的需要一个强有力的技术领导。
PAT 也有这种感觉，尽管被推到了新的 PAT 中，但我用到的大多数东西仍然需要传统的 PAT。而且文档也很糟糕。我也有同样的想法，PAT 过渡和 API 过渡给人的感觉就像一个未完成的功能。
对我来说，API 的过渡更加奇怪，因为用 GraphQL 封装 REST 调用几乎是小菜一碟。
在我看来，GitHub 的技术欠账越来越严重，却没有得到解决，如果这还不能说明 GitHub 这样的产品出现了问题，那我就不知道还有什么能说明问题了。
文章中的抱怨是合理的，而且听起来完全有可能是因为重写了 React，因为作为性能优化，避免渲染屏幕外的内容是 React 中相当标准的做法。
但这其实是重写的管理问题，与技术无关。github 上有人决定不呈现屏幕外内容。这与之前的工作方式相比打破了人们的预期，这就是为什么感觉应用程序在走下坡路。
更重要的一点是，如果有人要重写，并试图与现有的用户体验相匹配……这需要更深层次的匹配，而不仅仅是将像素放在正确的位置。
这是因为负责这项技术的人不知道人们想如何使用这项技术。
这意味着你可以期待它继续走下坡路，直到有更高的人采取行动。
我经常听到这种观点（尤其是在 Twitter 上），但我完全不同意。我认为 Github 仍然是一款了不起的软件，而且微软对它的投资几乎超过了最近从任何母公司收购的任何项目。
对于一个在非常复杂的软件中突然出现的 bug，这感觉就像一个非常戏剧化的框架。
但这并不是一个错误。就像现在的许多网站一样，为了节省客户端浏览器的带宽和资源，它们在导航时不会加载整个页面，这是一种有意的设计选择。
我以前也被这个问题困扰过。在查看一个拉取请求的文件选项卡时，我按下 ctrl-f，开始键入一个我知道是 PR 一部分的文件名，结果……什么都没有。找不到。找不到。
直到我向下滚动了一点，页面上的 JS 才加载了更多的差异，然后我要找的文件就出现在了列表中，点击后就可以滚动到该文件。
这种懒加载方式可以节省客户端和服务器的系统资源，但却降低了可用性。
这种模式太令人沮丧了–尤其是当他们在页面中捕获查找热键，但直到 js 完全加载后才捕获热键时。这让我不禁要问，将浏览器查找事件暴露给页面是否会有所帮助–通过确保整个 dom 已加载并可搜索来处理查找事件。
> 这可能是为了节省客户端浏览器的带宽和资源而故意做出的设计选择。
完整的源文件可能只是 React 垃圾文件的一小部分。
与其说他们是在通过虚拟视图限制 DOM 的大小，不如说是在限制下载的大小。不幸的是，HTML 虚拟视图会破坏页面中查找等功能。
我觉得 “Github 仍然是一款了不起的软件 “和 “GitHub 有一些恼人的 bug，实在不该有 “这两种观点其实并不冲突，它们可以同时成立。
我之所以使用 GitHub，是因为它仍然是最好的选择，而且还有相当大的优势。[1] 但我也认为它有一些愚蠢的 bug（有时要花很长时间才能修复）、一些错误的设计，有时甚至是完全错误的功能。
例如，如果你使用浅色方案，GitHub 的操作日志就会显示为对比度相当低的深色。这对我来说非常难以阅读；我使用浅色主题是有原因的。所以我需要打开 “原始日志”，然后从那里查看。这可行吗？可以。我是否非常讨厌使用 GitHub Actions，因为它的工作流程实在太烦人了？是的。
GitHub 讨论几乎毫无用处。试着在一个较大的线程上发表评论，你会很难找到自己的评论，也很难看到是否有人回复。制作一个比 Twitter 更混乱、更糟糕的对话用户界面是一项相当大的成就，但 GitHub 却做到了。
其中有些功能令人费解；这些都不是新功能，而且很容易上手。就像 “后退 “按钮的功能在半年或更长的时间里都无法正常使用，直到他们最终修复了它。
[1]: 我已经有一段时间没有评估 Gogs/gitea/Forgejo 了。另外，整个双叉的事情也有点令人遗憾。
100%同意。
这绝对是一个了不起的平台。
事实上，令人惊讶的是，即使在收购和压倒性采用之后，它仍然保持着高质量。我预计范围蠕变会无限制地增长。
我还记得 Jira 推出这种完全相同的文本渲染回归时的情形。我们工作时使用的看板上几乎没有人，通常只有不到 20 张票据。我点击 ctrl+f 跳转到我想要的票单编号，结果……什么都没有。浏览器找不到它！原来，票单略低于视图端口，而同时呈现 20 张票单对于现代票单网络应用来说显然是太多了。
现代框架中的倒退数量有时令人咋舌。就我个人而言，在一个资源充足的项目中处理如此基本的任务都会让我感到尴尬，但我相信引入这种回归的重新设计是使用了各种在简历上看起来很不错的流行框架和模式。
我觉得ctrl/cmd f在整个网络中都受到了很大的冲击。它曾经是一个非常可靠的工具，能让你最快到达你想去的地方。
GitHub 的 Web UI 要改用 react 了？可悲的是，Rails 提供了使用 websockets（如 Elixir Liveview）提供异步更新视图的方法。在发现尽可能多地使用 Rails 更易于维护后，我几乎放弃了 Vue。不仅是我自己，整个团队都能通过这种方式加快工作进度。后端人员通常对前端有足够的了解，但可能并不了解 Vue/React 的深奥之处，因此在分配简单任务时会造成延误。再加上大量重复的逻辑（权限、模型等）。
你需要一些相当严重的 “桌面风格”（讨厌这个词）用户界面复杂性来要求 React，而我并不完全明白 GitHub 需要的是什么。
也许他们想把 GitHub 变成浏览器中的 VSCode？
> 也许他们想让 GitHub 像浏览器中的 VSCode 一样？
已经可以了。在任何版本库中按下”. “键，就能在浏览器中用 VS Code 打开版本库。
在微软接管之前，GitHub 在相当长的几年里一直停滞不前。还记得因为会复制行号而无法有意义地复制代码吗？花了那么长的时间才解决，有点可笑。但最近几年……是的，我觉得它变得越来越烦人了。我有时真的怀疑，GitHub 的工作人员自己是否真的在使用它。
我曾试着向 GitHub 报告一些非常明显且恼人的 bug，但它们甚至从未被修复，或者花了几个月才被修复，或者修复后过了一段时间又坏了。我也就不再理会了。
GitLab 还是比 GitHub 差很多。
至于 React，不幸的是，有一部分前端开发者似乎认为所有东西都必须使用 React，React 是唯一可能的答案，而所有不使用 React 的人都是腐朽的开发者，可能是腐朽的人，也很可能是注册过的无名小卒，他们通常会永远大谈 React，直到全世界都改用 React。你的前端将被同化。
React 并不是唯一存在这种问题的技术，但它可能是最令人沮丧的技术之一，因为作为用户，我并不关心你使用的是什么语言或数据库，因为我通常并不真正接触这些语言或数据库，但我确实直接接触了你的前端。
TIL React 开发人员是 GNOME 开发人员
别再做这些零努力零内容的离题刷屏了。这里明确规定不允许这样做。
请不要这么说！
他们会去 “现代化 “它，让它成为一个速度慢 10 倍、更加臃肿的讨厌的网络用户界面，并为了它而移动所有按钮和 URL。
这在某种程度上已经发生了。Repo 文件和侧边栏都是客户端加载的，速度很慢。
我认为，文章中阐述的许多问题都是 GitHub 最近 “现代化 “转向 React 的结果。
这篇文章正是在抱怨 “现代化”。
它现在是一个 rails 应用程序，所以如果有其他东西会变慢，我会很惊讶的，lol。除非他们真的搞砸了重写什么的，但从技术角度来说，几乎任何其他东西都会更快。
你可能需要仔细读一下这篇文章： 它抱怨的正是这一点。
> 并找到一个能像 GitHub 网页界面一样好用的本地责备工具
我不知道你到底想要什么，但如果你想更好地查看 git blame、git show、git diff 等，我建议你用 delta。Delta 可以格式化这些 git 命令的输出，让你以更漂亮的方式查看它们的输出。你还可以用它来替代人类可读的 diff。更多信息：https://dandavison.github.io/delta/
不过，尽管 git blame（及其图形界面）是一款快速简便的工具，但它也存在一些问题，而 Git 有更好的代码考古工具。更多信息请参见：https://news.ycombinator.com/item?id=39877637
此外，如果你是 Emacs 用户，它的 VC 软件包也非常强大。例如，”C-x v g “可以调出 “责备”（vc-annotate）视图，你可以（对任何提交）按 “a “查看提交前文件的样子，按 “d “查看提交的差异，按 “l “查看提交信息……。这只是冰山一角。它的后台支持 Git、Mercurial、Bazaar、CVS、Subversion 等。
https://www.emacswiki.org/emacs/VersionControl
我曾使用 GitHub 多年（2009-2014 年），后来被一家大型科技公司收购了 8 年，因此没怎么用过它，后来又回到一家使用它的初创公司，感觉它就像一个完全不同的产品。从这个角度看，这是一个截然不同的产品。
GitHub Actions 是其中重要的一部分。Codespaces 是 Mac CI 的解决方案，可以自动执行大量工作、存储秘密、从 GitHub 直接驱动 CI 和 CD 等。它的发展可谓一日千里。此外，公司还在通过 copilot 和 vscode（以及以前的 atom）做其他事情。
当然，代码搜索只是略有改善，也许 Git 的某些核心功能在用户界面上没有那么炫目，但它已经有了长足的进步。
代码搜索是我最希望看到改进的一点。
只要雇一个曾在谷歌工作过的人，复制他们的内部代码搜索就可以了。
(预览：https://source.chromium.org/）
技术注意事项：为了有效工作，它需要能够编译代码（将代码解析为 AST），这对许多 GitHub 项目来说具有挑战性。不过我敢打赌，他们可以轻松达到 80% 的编译率，然后使用哑文本搜索来处理其余部分。
出于某些原因，禁用 JavaScript 并不总是对所有文件都有效；我也不知道为什么。有些文件即使禁用了 JavaScript 也能显示，但有些文件却无法显示。有些文件在禁用 JavaScripts 后只能部分运行。
不过，即使不起作用，服务器也会把 JSON 作为 HTML 文件的一部分发送，其中包含所有相关数据，所以我自己写了一个脚本，它比 GitHub 中的脚本短得多，速度也快得多，还能避免下载脚本时需要额外请求。
此外，它还支持 git 协议，因此仍然可以使用，而且还有 API。幸运的是，它有很好的文档，而且在没有 JavaScripts 的情况下也能工作（文档应始终在没有 JavaScripts 的情况下工作；如果您的网站有文档，但在没有 JavaScripts 的情况下无法工作，请纠正这一点，即使其他文件在没有 JavaScripts 的情况下无法工作是有正当理由的（这种情况并不常见，因为通常是没有正当理由的））。
尽管如此，他们必须这样做并不是很好，他们应该让设计工作不至于如此混乱。(他们在这篇文章中描述的方式，确实存在那里描述的问题和更多问题；这是因为 WWW 的杂乱无章，但他们可以避免使用许多较新的东西，使其更加兼容，提高可访问性，并避免许多需要添加考虑的问题，而如果设计得当，这些考虑甚至是不必要的（因为这样客户端就能够根据用户的偏好自动处理，而不需要服务器告知）。
能分享一下你的脚本吗？
我觉得 GitHub 大体上还不错。
但代码审查是个例外，这可以说是它最重要的用例。一旦有了一些来来回回的修改，再经过几轮修改，就很难找到评论列表了。也许是我遗漏了某个地方，但在对话选项卡中散布是不可能找到的。
我用了几个脚本，把所有的线程拉到一个我可以用 vim 打开的文件里。然后我就有了跳转到代码中相应位置的快捷方式。效果不错，但似乎真的没有必要。
> 感觉像遗留软件
鉴于他们的博客设计让人联想到 24 年前 OS X 的 “金属拉丝 “主题，这样说有点讽刺意味
https://en.m.wikipedia.org/wiki/Aqua_(user_interface)#/media…
很多老软件都比现代软件更好用。
用户体验不仅仅是视觉上的美观，同样重要（或更重要）的是它的行为方式、用户与它的交互方式，以及它如何摆脱你的束缚，让你完成实际工作（或不完成工作）。
我不反对。
但作者的意思是 “传统=糟糕”。
注：我真心喜欢 Windows 2000 的用户界面/用户体验（并希望它今天仍然存在）
我认为这是一个完美的小细节，它捕捉到了这位作者的个性。他们的博客使用的是曾经非常著名和流行的 Octopress [0]。每个开发人员都在用它运行自己的博客。
我想说的是，看起来作者找到了一个十多年来一直行之有效的东西。他们希望 GitHub 能 “正常工作
0: http://octopress.org/
我觉得这个设计没那么老。早在 11 年前，我就从事网页设计工作了，当时很多设计理念都很 “流行”。微妙的明暗 1px 线条营造出嵌入式效果，某些元素周围有一些阴影，而不是完全琐碎的排版。这是 2010-2014 年的设计类型。
这个博客使用的是不支持的软件（Octopress）。我认为它自 2016 年以来就没有更新过。
不久前，我开始尝试构建一个本地优先的 GitHub 客户端：https://github.com/tinyplex/tinyhub
看起来，GitHub 的界面更像是一个 “应用程序”，而不是一个 “网站”。是我的错觉？
> 还是只有我？
我只是一个数据集，但我不同意。在这一点上，Github 这个网站已经运行了十多年，效果相当不错。正如帖子作者所说，最近才开始出现一些裂缝。
它的主要用途是浏览文档。
这并不是说它不是一个应用程序，而是说它的许多目标应该与浏览器类似。
这种感觉，再加上它们缺乏堆叠支持，促使托马斯、梅里尔和我在 graphite.dev 上黑了好几年。
最近有一次，我试图理解 “为什么开发人员会在我使用的应用程序中创建这样的界面”，这时我意识到，我看到的基本上是一个 “React 类型的界面”，而这并不适合，”为什么 “也许是因为年轻的开发人员习惯于看到/实现这样的东西，所以他们可能根本意识不到这是一种糟糕的方法。
我希望所有的软件都能像传统软件一样。
听起来其实是个 bug。在我编写的应用程序中，如果有人报告了类似的问题，我就会把它视为 “错误”，并设法解决。
> 我看到很多工具都陷入了瓶颈。
我认为这是开发平台的理想状态。不断调整可能会导致很大的问题（听起来就像这里发生的情况）。我曾在 Xcode 上放过一个大屁。
GitHub 的通知是最糟糕的。完全没用；不，是令人愤怒。这是他们首先应该改进的地方。
虽然我理解在差异文件中折叠大文件的动机，因为你想保持较低的 DOM 元素数量，但拜托……你真的不能把 PR 中的大部分改动隐藏起来。至少让折叠文件更突出一些，这样你在审阅时就不会错过它们了。或者，我猜你是不想让我扩充它们，或者你无缘无故地做了那么多折叠工作。那么重点又是什么呢？
10 年前就提出了机关准则，但至今仍未落实。看起来很简单……
我觉得这篇文章的关注点太狭隘了。Github 要解决的问题多种多样，受众也各不相同。人们使用 Github 和 Git 的方式完全不同，因此存在空格键加热问题。他们的 “责备 “视图，也就是这篇文章一半的内容，我很少用过。同样，有些团队会在代码审查期间重定向，有些则在审查之外处理，等等等等。
至于 Ctrl+F 的问题，我认为使用语法高亮渲染巨型文件会降低旧电脑的性能，而且他们正试图为使用 Github（网络版–请记住）的用户解决这个问题，因为如果你需要完全的可搜索性，你可能会在本地克隆 repo。
我不知道，也许 Github 在幕后把一切都搞砸了，但在我看来，这篇文章并没有提出令人信服的论据。
我已经很久没有看到 octopress 网站了。我怀念octopress，怀念与之相伴的个人网站写作文化。基于最大写作速度和效率的共享模板。
有人知道 Git 的客户端责备前端吗？我以前用的是 Git Extensions 的那个，但不知从什么时候开始，它就不能用了。
如果可以选择 TUI，那么 “tig blame “是个不错的界面。
https://github.com/jonas/tig
“git gui blame “也不错，而且 git 自带了 git-gui。
> 但不知从什么时候开始，它就不再为我工作了。
我更新了 Git 和 Git 扩展，似乎解决了这个问题，但我遇到的问题都是零星的，也许是我运气好吧。
JetBrains 集成开发环境中的那个很不错。”注释以前的修订 “非常有助于及时回顾。
我想大多数现代集成开发环境和文本编辑器都至少有一个。我记得的有
– JetBrains 的 Annotate
– VSCode 的 GitLens
– Emacs 的 Magit
Tortoisegit?
> 问题不在于我想要的那一行不在页面上，而在于整个文档没有被同时渲染，所以我的浏览器内置搜索栏无法找到它。
Ctrl/Cmd-F 在责备/代码页面上会被拦截，并打开一个自定义的查找用户界面，老实说，我觉得这样很好。浏览器的 “页面内查找 “功能并不是用来搜索代码的，而且速度很慢。
也许 GitHub 正在改用 React（我对此一无所知），但 React 并不强制或甚至原生支持删减屏幕外的内容，所以我不确定这其中有什么联系。
我讨厌现在的内容渲染效率如此之低，以至于无法一次性渲染整个文档，从而破坏了浏览器内置的搜索功能。这感觉就像是现代软件的倒退。
Slack 就是这样做的，我非常讨厌。在长线程中搜索关键词是不可能的。原生应用会直接劫持搜索功能，即使在浏览器上打开也不行，因为它只会渲染屏幕上的部分。我相信有人在实现这个功能时一定觉得自己很聪明。
如今，考虑到如此多的网站都是网络应用而非网页，网络确实值得被视为操作系统或应用平台。
如果有一个既定的工具，可以上下滚动屏幕上无法显示的文档就好了
等待
> 所以我不知道这其中有什么联系。
我不认为他们会特别指责反应。更多的是，对他们来说，当他们想起阅读前端是用 react 重写的时候，才恍然大悟，这可能是重写造成的。
我越来越反感 react 了。我每天都要处理 UI 滞后问题，而且每天都要处理很多次，这让我非常恼火。我已经厌倦了从手指开始移动到鼠标点击或手指点击触摸屏时按钮移动的过程，因为一个模块比其他模块晚加载十秒钟。
要想获得指责视图，OpenGrok 有一个 “注释 “功能。
是的，我不太喜欢 GitHub（尤其是在微软收购之后），但我也讨厌那种 “我们需要发展”、”我们需要扩张 “的愚蠢态度。有时候，工具已经做好了，能改进的地方实在不多。尤其是从用户界面的角度来看。如果你开始强行改进，通常会导致设计过度，使用起来很痛苦。
并不是说传统的东西就一定不好或应该避免。事实上，大多数情况下是相反的。这意味着它很稳定，能帮助你完成工作。在我看来，传统与进步之间的平衡并不那么明显。
老实说，我不知道这个博客是不是在耍流氓，但这里的评论表明他们不是。
难道只有我一个人满足于在终端运行 `git blame`，使用 `less` 作为寻呼机，然后按 `/` 进行搜索吗？
GitHub 正在慢慢将社交功能置于开发者工具和体验之上。现在关注 GitHub Stars 的开发者数量有点令人担忧。我觉得每周至少都能在 HN 上看到一篇帖子，询问如何提高 GitHub 仓库的星级。
它们显然可以像其他平台上的指标一样被购买。
有人用它们来骗人，他们克隆一个合法项目，添加一个后门，然后购买星级并进行搜索引擎优化，让人们克隆这个糟糕的 repo。
Gitlab 比 Github 快多了。
Gitlab 在很多方面确实比 Github 好（除了设置菜单的老鼠窝）。
举例来说，如果你合并了一堆分支中的中间分支，gitlab 会重定向更高的分支。而 Github 只会让它们成为孤儿。
有意思。我上一次使用 gitlab 是在 2021-22 年，主观上感觉它们不相上下。你有任何基准或其他来源吗？
有啊。这是一个大屁股的古董 rails 应用程序，试图用 turbolinks 来提高速度。
Rails 应用程序不是问题。问题在于一大堆与协作或代码版本管理无关的噪音和功能。
我自己也喜欢 Rails，并不是说它不好。不过，可能早就该有类似 SPA 的体验了。很多用户界面都太过时了。事实上，公关中最基本的东西都被隐藏在披露菜单下面，而如果没有菜单，就有足够的空间将其置于线内，这让人很沮丧。比如编辑 PR 的描述就需要点击两次，而点击一次就可以了。一切都让人感觉是临时拼凑的。比如将 PR 标记为草稿……我第一次就花了很长时间才找到。
产品设计的质量与这些内容如何到达你的浏览器之间没有任何关联。c