我对 pull 请求、编辑问题并将它们绑定(bind)到提交以及我通常必须使用的其他东西特别感兴趣 hub on the command line为了。然而，我已经开始使用 magit 并且真的很喜欢它的键绑定(bind)和通用界面——我也想在这部分留在 emacs 中，而不是需要为 pull 请求、问题等打开一个额外的 shell。
我能找到的可能为 magit 添加最多 github 功能的包是:
任何可能参与这些项目的人都可以推荐他们如何比较以及将 pull 请求集成到 magit 环境中的最佳方式吗？
最佳答案
最终我会在 Magit 中实现这些东西(我是维护者)，但我首先必须发布一个版本。
旧的过时信息:不幸的是，目前还没有第三方扩展可以填补这个角色。 magithub 已经坏了很长时间了。 magit-gh-pulls(Yann，我的前任 Magit 维护者)也没有与 Magit 的变化保持同步。前段时间我试图修复它，但是当很明显这样做会导致完全重写时我放弃了。 gh.el 也是 Yann 写的，被 magit-gh-pulls 使用。我过去曾为它做出过贡献，但最终停止使用它，因为 (a) 它使用 url.el 结果证明它非常不可靠 (b) 它过于复杂。
所以恐怕目前没有一个包可以满足您的需求。如果您想自己编写，我建议您使用 request.el，然后只实现您实际需要的 Github api 部分，以避免过度设计。
编辑:截至 2015 年 10 月 magit-gh-pulls 是 maintained再次，但不再是官方扩展。我个人不使用它，因为我认为它应该或多或少。我目前使用来自 magit-rockstar 的 magit-branch-pull-request 形式的“less”图书馆。即使我维护该库，我也不认为它是官方扩展——它是按原样提供的。该功能非常基本，您给它一个问题编号，它会为您创建一个分支，仅此而已。
2016 年 9 月编辑: 我写了 ghub.el和 glab.el作为 gh.el 的替代品。它们主要供我个人使用，提供的非常很少，基本上它们为您提供了诸如ghub-get (resource &optional params data noerror) 之类的功能，然后您必须查看相应的 api 文档，找出您必须使用的 resource、params 和 data。错误处理也不是很好，目前使用 url.el。我打算在支持 ffi 的 Emacs 发布后的某个时间通过使用 libcurl 最终改进这两者。
2020 年 1 月编辑:一年多以前我有 released forge .
Forge allows you to work with Git forges—such as Github and Gitlab—from the comfort of Magit and the rest of Emacs.
关于git - 针对 pull 请求的 emacs 开发最多的 magit/github 扩展，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24001651/