… 看着它如此痛苦，因为我如此热爱GitHub。我于2013年大学毕业，这意味着我在他们起步的时候就开始编程了。我每天都阅读他们的开发博客，急切地等待新功能的发布（每隔几天就会发布一次）。我看着他们的团队页面逐渐壮大，仔细观察他们做了什么才得以进入这样一家酷炫的公司。我研究他们贡献回的项目，以寻找好代码的线索（我最喜欢的的是Vicent Martí对libgit2的贡献）。我热切地教我的朋友如何使用git，因为大学里教的是subversion。我通过编写自己的Rails教程来学习其中的奥秘。但这么多年过去了，这种爱变得不再容易。这是工作！看着它不断被新兴公司超越，真的非常痛苦。我一直以为核心功能（拉取请求和问题）最终会变得更好。而现在，14年后，它们终于开始变好了。但非常缓慢。我真的想相信，但经过16年，我开始意识到GitHub可能只是一个存储文件的地方。魔法仍然存在。…
源讨论GitHub引入了子问题、问题类型和高级搜索原帖 206 条评论 · 导入时统计把你的经验，加入这段讨论。
顺便说一下，这个特定功能——他们现在称之为子问题——实际上更准确的描述是他们系统中建模正确父子关系的框架，这是一件很难做对的事情，主要是因为它必须以某种方式与现有的问题功能集协同工作。从零开始构建此功能的人（例如Linear）可以轻松解决这个问题，因为他们不需要担心任何向后兼容的问题。当然，这绝对是GitHub的错，因为他们在最初设计时没有让这种东西容易实现，但构建此功能的人可能并不是当初做出那个原始决定的人。 他们已经在这个功能的某个版本上工作了好几年，经历了多次迭代。我认为这可能是他们第三次或第四次尝试将其做好——我之前试用过某个先前版本的测试版。…
完整原文我喜欢GitHub，正是因为它没有过于激进地试图占据问题跟踪器和代码搜索市场的全部份额。 如果在2019年就有类似GitHub子问题的功能，哪怕功能较为逊色，针对开发者的跟踪工具如Linear和Shortcut就很难生存下去，而它们的许多想法（其中一些甚至已经影响了如今GitHub子问题功能的用户体验！）也将被时间所埋没。 现在，也许这对微软来说并不是价值最大化的选择，或者对现在需要为Linear额外购买许可证的公司来说也不是价值最大化的选择，但我认为，对于真正的开发者体验来说，GitHub通过自身的停滞促进创新精神，创造了一个比任何公司自己所能创造的都要更活跃的生态系统。
完整原文> 很可能至少会有3家上市公司，它们本应只是GitHub的功能：GitLab（GitHub Enterprise）、Sourcegraph（搜索功能）和Linear（GitHub问题）。 我不认同这个观点，我无法理解什么样的思维过程会得出这样的结论，即每个对任何开发人员的工作流程至关重要的功能都应该毫无理由地被分解为外部公司。 任何开发人员的工作流程包括a) 任务管理，b) 版本控制，c) 审核代码和变更历史，d) 持续集成和持续部署（CICD）。显然，a)、b) 和 c) 是紧密相关的，你不能没有其他而单独存在，而 d) 在任何事件响应场景中都会导致 a)、b) 和 c)。没有任何理由能证明替代统一的开发人员体验是合理的。
完整原文不要忘记代码审查。我创建了CodeApprove，但还有许多其他优秀的替代方案本可以成为GitHub的功能（如Graphite、CodePeer、Reviewable等）。
完整原文GitHub是一家非常成功的公司。他们赚了很多钱。你对成功的定义与实际的成功并不一致。
完整原文> 我开始编程的时候，他们也刚刚起步。 那么让我告诉你关于SourceForge的事情。在GitHub起步的时候，SourceForge拥有许多这些功能（至少当时的标准功能）。它是当时开源软件开发的默认场所，但它也是一个试图做所有事情的巨无霸。 GitHub正是因为它在极简主义和功能之间取得了恰到好处的平衡，而成为了一股清新的空气。当时有很多真正极简的主机，所以我们不需要更多这样的了。但我们也有很多臃肿和缓慢的代码主机。需要强调的是，这些臃肿的产品和极简的产品一样难以使用，尽管它们（再次，就当时而言）功能上是相当完整的。 臃肿的产品无法转型。新功能往往无法与现有功能良好集成，而且它们往往需要很长的时间来实现…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。