为GitHub提供堆栈差异支持
项目描述
ghstack
方便地将差异堆栈提交给GitHub作为单独的pull请求。
pip3 install ghstack
ghstack已在多个不同的Python版本上进行了测试 （链接）。它至少需要Python 3.8.1。
如何设置
前往github.com 设置→开发者设置→个人访问令牌，并仅使用public_repo访问权限生成令牌。创建一个~/.ghstackrc，如下所示
λ cat ~/.ghstackrc
[ghstack]
github_url = github.com
github_oauth = [your_own_token]
github_username = [your_username]
remote_name = upstream [if remote is called upstream and not origin]
如何使用
确保您有写入您正在打开PR的仓库的权限。
在master之上准备一系列提交，然后运行ghstack。此工具将为堆栈中的每个提交推送并创建pull请求。
如何将另一个PR堆叠在现有PR之上？ 假设您已经从现有的PR中检出最新提交，只需在顶部git commit一个新的提交，然后运行ghstack。
如何修改PR？ 只需编辑相关的提交，然后再次运行ghstack。如果提交在堆栈的顶部，您可以使用git commit --amend进行编辑；否则，您必须使用git rebase -i直接编辑提交。
如何进行变基操作？ 显而易见的方式：git rebase origin/master。不要进行 git merge；如果你这样做，ghstack 会表现得非常不满。（这也有一个更基本的原因，为什么这不会奏效：因为每个提交都是一个单独的PR，你必须为每个PR解决冲突，而不仅仅是整个堆栈。）
如何开始一个新功能？ 只需在新分支上检出master，然后从一个新的分支开始工作。
警告。 你将无法使用正常的GitHub UI合并这些提交，因为它们的分支基础不是master。使用 ghstack land $PR_URL 来提交一个ghstack的pull request。
提交的pull request结构
你本地提交堆栈中的每个提交都会作为一个单独的pull request提交，并将提交推送到三个分支上
-
gh/username/1/base- 将其视为“master”：这是你的提交基于的分支基础。它永远不会被强制推送；无论何时你变基本地堆栈，我们都会在上面的基础分支上添加来自真正上游master的合并提交。 -
gh/username/1/head- 这是你的更改，位于基础分支之上。像base一样，它也永远不会被强制推送。我们在该分支上打开pull request，请求将其合并到base。 -
gh/username/1/orig- 这是你的本地副本中的实际提交。GitHub的pull request永远不会看到这个提交，但如果你想要一个“干净”的提交，例如，因为你想要在其他机器上处理提交，这是获取它的最佳方式。
开发者说明
该项目使用 Poetry，因此在你安装了Poetry本身之后，请在该repo的克隆副本中运行此命令来安装所有需要的依赖项，以便在 ghstack 上工作
poetry install
请注意，这会将依赖项（以及 ghstack 本身）安装在一个隔离的Python虚拟环境中，而不是全局安装。如果你当前的工作目录是此repo的克隆副本，则可以使用 poetry run ghstack $ARGS 运行本地构建的 ghstack，但如果你想要在其他位置运行它，你可能想要使用 poetry shell。
poetry shell
cd $SOMEWHERE
ghstack $ARGS
测试
我们使用模拟GitHub GraphQL服务器进行测试！这有多酷？
poetry run python test_ghstack.py
这运行了大多数测试；你可以这样运行所有测试（包括lints）
poetry run python run_tests.py
发布
你也可以使用 Poetry 发布到包仓库。例如，如果你已经像这样配置了你的 Poetry 仓库
poetry config repositories.testpypi https://test.pypi.org/legacy/
然后你可以这样发布到TestPyPI
poetry publish --build --repository testpypi
要发布到PyPI本身，只需省略 --repository 参数。
设计限制
GitHub的设计有一些奇怪之处，这导致这个工具做出了不寻常的设计决策。
-
当你创建GitHub上的PR时，它总是会创建在基础分支存在的仓库上。因此，我们必须将分支推送到你想要创建PR的上游仓库。这可能导致许多过时的分支挂在那里；你需要设置某种其他机制来修剪这些分支。
-
分支名称与pull request编号不对应。虽然这会很理想，但我们无法预留pull request编号，所以我们不知道它是什么，直到我们打开pull request，但我们不能没有分支就打开pull request。
Ripley Cupboard
模仿Conor McBride，本节记录了值得注意的错误。
非堆栈模式。 ghstack 在上传更新时处理整个堆栈，但不必这样；你可以想象请求 ghstack 只处理顶部提交，其余的保持不变。一种简单且引人注目的方法是编辑堆栈选择算法，使其只查看单个提交，而不是从合并基础到头的所有提交。
这听起来不错，但当你尝试时，你会意识到两件事
-
这是错误的，如果你排除了你之前的提交，你最终会得到一个基于 Git 仓库中“字面”提交的基提交。但这与之前上传的基提交没有任何关系，后者是合成的。
-
你还需要额外的工作来拉取最新的堆栈以写入拉取请求正文中。
因此，这并非不可能做到，但需要一些工作。你必须确定真实的基提交是什么，是否需要将其推进，并重新编写堆栈渲染代码。
下载文件
下载适用于您的平台的文件。如果您不确定选择哪个，请了解更多关于 安装包 的信息。
源分发
构建分发
ghstack-0.9.3.tar.gz 的哈希值
| 算法 | 哈希摘要 | |
|---|---|---|
| SHA256 | 90a0c09ec8f463ef73939d1620448a9c4d723b3e9f887dc97f08be4b2163193f |
|
| MD5 | 678df232a1425ec40ba3f0d6954eb237 |
|
| BLAKE2b-256 | 0b42f5643a1bb9fff547ef80651b1f145f44d05d6436c2b729d156ab5a0b2bfc |
ghstack-0.9.3-py3-none-any.whl 的哈希值
| 算法 | 哈希摘要 | |
|---|---|---|
| SHA256 | dff4365f07c03fdecbdf4989975bb57f20f04218b713e280ad8d34d833aa7830 |
|
| MD5 | 63f6787917f98ba567890179fe220338 |
|
| BLAKE2b-256 | 8da0dc5cb17b47c954731ae451a70b9ac9a89089ef946ca2e27d2f3471c71a7a |
