开发工作流程#
您已经拥有 NumPy 存储库的独立分支副本,配置了 Git,并按照 将您的仓库链接到上游仓库 中的说明链接了上游仓库。下面介绍的是推荐的 Git 工作流程。
基本工作流程#
简而言之
这种工作方式有助于保持工作井井有条,并使历史记录尽可能清晰。
创建新的特性分支#
首先,从 upstream 仓库获取新提交
git fetch upstream
然后,基于上游仓库的主分支创建一个新分支
git checkout -b my-new-feature upstream/main
编辑工作流程#
概述#
# hack hack
git status # Optional
git diff # Optional
git add modified_file
git commit
# push the branch to your own Github repo
git push origin my-new-feature
更详细地说#
进行一些更改。当您觉得已经完成了一组相关的、可正常工作的更改时,请继续进行下一步。
可选:使用
git status检查哪些文件已更改。您将看到类似以下的列表# On branch my-new-feature # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # INSTALL no changes added to commit (use "git add" and/or "git commit -a")
可选:使用
git diff将更改与前一个版本进行比较。这将打开一个简单的文本浏览器界面,突出显示您的文件与前一个版本之间的差异。使用
git add modified_file添加任何相关的已修改或新文件。这将把文件放入暂存区,这是一个将添加到下一次提交的文件队列。仅添加具有相关、完整更改的文件。将具有未完成更改的文件留待稍后提交。要将暂存的文件提交到您仓库的本地副本,请执行
git commit。此时,文本编辑器将打开,允许您编写提交消息。阅读 提交消息部分,以确保您编写了格式正确且详细的提交消息。保存消息并关闭编辑器后,您的提交将被保存。对于微小的提交,可以使用命令行中的-m标志传递简短的提交消息。例如,git commit -am "ENH: Some message"。在某些情况下,您会看到此形式的提交命令:
git commit -a。额外的-a标志会自动提交所有已修改的文件并删除所有已删除的文件。这可以为您节省输入许多git add命令的麻烦;然而,如果您不小心,它可能会将不必要的更改添加到提交中。将更改推送到您的 Github 分支
git push origin my-new-feature
注意
假设您已按照这些页面的说明进行操作,git 将创建一个名为 origin 的默认链接到您的 GitHb 仓库。您可以使用 --set-upstream 选项来确保到 origin 的链接永久设置
git push --set-upstream origin my-new-feature
从现在开始,git 将知道 my-new-feature 与您自己的 GitHub 仓库中的 my-new-feature 分支相关。随后的推送调用会简化为以下命令
git push
您必须为创建的每个新分支使用 --set-upstream。
您在进行编辑时,upstream 可能已添加了影响您工作的新提交。在这种情况下,请按照本文档的 在主分支上变基 部分将这些更改应用于您的分支。
编写提交消息#
提交消息应清晰并遵循一些基本规则。例如
ENH: add functionality X to numpy.<submodule>.
The first line of the commit message starts with a capitalized acronym
(options listed below) indicating what type of commit this is. Then a blank
line, then more text if needed. Lines shouldn't be longer than 72
characters. If the commit is related to a ticket, indicate that with
"See #3456", "See ticket 3456", "Closes #3456" or similar.
描述更改的动机、错误修复的 bug 性质或增强功能的功能等细节也包含在提交消息中是很好的。消息应在不查看代码更改的情况下即可理解。像 MAINT: fixed another one 这样的提交消息是应该避免的例子;读者必须到别处查找上下文。
以提交消息开头的标准缩写是
API: an (incompatible) API change
BENCH: changes to the benchmark suite
BLD: change related to building numpy
BUG: bug fix
CI: continuous integration
DEP: deprecate something, or remove a deprecated object
DEV: development tool or utility
DOC: documentation
ENH: enhancement
MAINT: maintenance commit (refactoring, typos, etc.)
MNT: alias for MAINT
NEP: NumPy enhancement proposals
REL: related to releasing numpy
REV: revert an earlier commit
STY: style fix (whitespace, PEP8)
TST: addition or modification of tests
TYP: static typing
WIP: work in progress, do not merge
跳过持续集成的命令#
默认情况下,许多持续集成 (CI) 作业都会运行,从在不同操作系统和硬件平台上运行测试套件到构建文档。在某些情况下,您已经知道 CI 不是必需的(或者不是全部),例如,如果您处理 CI 配置文件、README 中的文本或其他不涉及常规构建、测试或文档顺序的文件。在这些情况下,您可以通过在 PR 的每个提交消息中包含一个或多个这些片段来显式跳过 CI
[skip ci]:跳过所有 CI仅建议在您还未准备好让 PR 运行检查时使用(例如,如果这只是一个草稿)。
[skip actions]:跳过 GitHub Actions 作业GitHub Actions 是大多数 CI 检查运行的地方,包括 linter、基准测试、在大多数架构和操作系统上运行基本测试,以及多种编译器和 CPU 优化设置。请参阅这些检查的配置文件。
[skip circle]:跳过 CircleCI 作业CircleCI 是我们构建文档并存储生成的伪影以在每个 PR 中进行预览的地方。此检查还将运行所有 docstrings 示例并验证其结果。如果您不更改文档,但更改了函数的 API,例如,您可能需要运行这些测试来验证 doctests 仍然有效。请参阅这些检查的配置文件。
[skip cirrus]:跳过 Cirrus 作业CirrusCI 主要触发 Linux aarch64 和 MacOS Arm64 轮子上传。请参阅这些检查的配置文件。
测试构建轮子#
Numpy 目前使用 cibuildwheel 通过持续集成服务来构建轮子。为了节省资源,cibuildwheel 轮子构建器默认不会在每个 PR 或主分支提交上运行。
如果您想测试您的拉取请求是否会破坏轮子构建器,您可以通过在 PR 中最新提交的消息的第一行附加 [wheel build] 来实现。请仅对与构建相关的 PR 执行此操作,因为运行所有轮子构建既慢又昂贵。
通过 github actions 构建的轮子(包括 64 位 Linux、x86_64 macOS 和 32/64 位 Windows)将作为 zip 文件中的伪影上传。您可以从“轮子构建器”操作的“摘要”页面访问它们。通过 Cirrus CI 构建的 aarch64 Linux 和 arm64 macOS 轮子不可作为伪影使用。此外,轮子将在以下条件下上传到 https://anaconda.org/scientific-python-nightly-wheels/
每周 cron 作业或
如果 GitHub Actions 或 Cirrus 构建被手动触发,这需要相应的权限
如果构建是由以 v 开头的仓库标签触发的,轮子将上传到 https://anaconda.org/multibuild-wheels-staging/
征求邮件列表的意见#
如果您计划一个新功能或 API 更改,最好先向 NumPy 的 邮件列表发送邮件征求意见。如果您一周内没有收到回复,可以再次在列表中询问。
请求将您的更改合并到主仓库#
当您觉得您的工作已完成时,您可以创建一个拉取请求 (PR)。如果您的更改涉及 API 的修改或函数的添加/修改,请将发布说明添加到 doc/release/upcoming_changes/ 目录中,遵循 doc/release/upcoming_changes/README.rst 文件中的说明和格式。
获取您的 PR 审查#
我们尽快审查拉取请求,通常在一周内。如果您在两周内没有收到审查意见,请随时通过在您的 PR 上添加评论来请求反馈(这将通知维护者)。
如果您的 PR 很大或很复杂,在 numpy-discussion 邮件列表上征求意见也可能很有用。
在主分支上变基#
这会将您的特性分支更新为来自上游 NumPy GitHub 仓库的更改。如果您不是绝对需要这样做,请尽量避免,也许只在您完成时进行。第一步将是更新远程仓库,获取上游的新提交
git fetch upstream
接下来,您需要更新特性分支
# go to the feature branch
git checkout my-new-feature
# make a backup in case you mess up
git branch tmp my-new-feature
# rebase on upstream main branch
git rebase upstream/main
如果您对已在上游更改的文件进行了更改,这可能会生成您需要解决的合并冲突。在这种情况下,请参阅 下面 的说明。
最后,在成功变基后删除备份分支
git branch -D tmp
注意
在主分支上变基优先于将上游合并到您的分支。在使用特性分支时,不建议使用 git merge 和 git pull。
从错误中恢复#
有时,您会搞砸合并或变基。幸运的是,在 Git 中,从这种错误中恢复相对直接。
如果您在变基过程中搞砸了
git rebase --abort
如果您在变基后才发现搞砸了
# reset branch back to the saved point
git reset --hard tmp
如果您忘记创建备份分支
# look at the reflog of the branch
git reflog show my-feature-branch
8630830 my-feature-branch@{0}: commit: BUG: io: close file handles immediately
278dd2a my-feature-branch@{1}: rebase finished: refs/heads/my-feature-branch onto 11ee694744f2552d
26aa21a my-feature-branch@{2}: commit: BUG: lib: make seek_gzip_factory not leak gzip obj
...
# reset the branch to where it was before the botched rebase
git reset --hard my-feature-branch@{2}
如果您实际上没有搞砸,但存在合并冲突,您需要解决它们。
您可能想做的其他事情#
重写提交历史#
注意
仅对您自己的特性分支执行此操作。
您提交的提交消息中有拼写错误?或者您做了几次不成功的尝试,您希望后人看不到。
这可以通过交互式变基来完成。
假设提交历史如下所示
git log --oneline
eadc391 Fix some remaining bugs
a815645 Modify it so that it works
2dec1ac Fix a few bugs + disable
13d7934 First implementation
6ad92e5 * masked is now an instance of a new object, MaskedConstant
29001ed Add pre-nep for a couple of structured_array_extensions.
...
并且 6ad92e5 是 main 分支的最后一个提交。假设我们要进行以下更改
重写
13d7934的提交消息,使其更合理。将提交
2dec1ac、a815645、eadc391合并为一个。
我们这样做
# make a backup of the current state
git branch tmp HEAD
# interactive rebase
git rebase -i 6ad92e5
这将打开一个编辑器,其中包含以下文本
pick 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
pick a815645 Modify it so that it works
pick eadc391 Fix some remaining bugs
# Rebase 6ad92e5..eadc391 onto 6ad92e5
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
为了实现我们的目标,我们将对其进行如下更改
r 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
f a815645 Modify it so that it works
f eadc391 Fix some remaining bugs
这意味着(i)我们要编辑 13d7934 的提交消息,并且(ii)将最后三个提交合并为一个。现在我们保存并退出编辑器。
Git 随后将立即打开一个编辑器用于编辑提交消息。修改后,我们会得到以下输出
[detached HEAD 721fc64] FOO: First implementation
2 files changed, 199 insertions(+), 66 deletions(-)
[detached HEAD 0f22701] Fix a few bugs + disable
1 files changed, 79 insertions(+), 61 deletions(-)
Successfully rebased and updated refs/heads/my-feature-branch.
历史现在看起来是这样的
0f22701 Fix a few bugs + disable
721fc64 ENH: Sophisticated feature
6ad92e5 * masked is now an instance of a new object, MaskedConstant
如果出错了,如 上面 所述,仍然可以恢复。
删除 GitHub 上的分支#
git checkout main
# delete branch locally
git branch -D my-unwanted-branch
# delete branch on github
git push origin --delete my-unwanted-branch
另请参阅:https://stackoverflow.com/questions/2003505/how-do-i-delete-a-git-branch-locally-and-remotely
多人共享单个仓库#
如果您想与其他人在同一个仓库,甚至同一个分支上一起工作,那么只需通过 GitHub 分享即可。
首先,按照 制作 scikit-image 的独立副本(分支) 中的说明将 NumPy 分支到您的账户。
然后,转到您的分支仓库的 GitHub 页面,例如 https://github.com/your-user-name/numpy
点击“Admin”按钮,然后将其他人添加为协作者
现在所有这些人都将可以执行
git clone git@github.com:your-user-name/numpy.git
请记住,以 git@ 开头的链接使用 ssh 协议,是读写的;以 git:// 开头的链接是只读的。
您的协作者然后可以使用常规的
git commit -am 'ENH - much better code'
git push origin my-feature-branch # pushes directly into your repo
签出现有拉取请求中的更改#
如果您想测试一个拉取请求中的更改或在新的拉取请求中继续工作,提交需要克隆到您的分支仓库中的本地分支
首先确保您的 upstream 指向主仓库,如 将您的仓库链接到上游仓库 中的所述
然后,获取更改并创建一个本地分支。假设 $ID 是拉取请求编号,$BRANCHNAME 是您希望创建的新本地分支的名称
git fetch upstream pull/$ID/head:$BRANCHNAME
签出新创建的分支
git checkout $BRANCHNAME
现在您已经获取了拉取请求中的更改。
探索您的仓库#
要查看仓库分支和提交的图形表示
gitk --all
要查看此分支的提交线性列表
git log
回填#
回填是将 NumPy 的 main 分支中提交的新功能/修复复制到稳定发布分支的过程。要做到这一点,您需要从要回填的分支创建一个分支,选择您想要的来自 numpy/main 的提交,然后提交包含回填的分支的拉取请求。
首先,您需要创建将要工作的分支。这需要基于旧版本的 NumPy(而不是 main)
# Make a new branch based on numpy/maintenance/1.8.x, # backport-3324 is our new name for the branch. git checkout -b backport-3324 upstream/maintenance/1.8.x
现在您需要使用
git cherry-pick将 main 的更改应用到此分支# Update remote git fetch upstream # Check the commit log for commits to cherry pick git log upstream/main # This pull request included commits aa7a047 to c098283 (inclusive) # so you use the .. syntax (for a range of commits), the ^ makes the # range inclusive. git cherry-pick aa7a047^..c098283 ... # Fix any conflicts, then if needed: git cherry-pick --continue
您可能会在 cherry-pick 时遇到一些冲突。这些冲突的解决方式与合并/变基冲突相同。只是在这里您可以使用
git blame来查看 main 和回填分支之间的差异,以确保不会搞砸任何事情。将新分支推送到您的 Github 仓库
git push -u origin backport-3324
最后,使用 Github 创建一个拉取请求。确保它是针对维护分支而不是 main 的,Github 通常会建议您将拉取请求针对 main。
将更改推送到主仓库#
需要向主 NumPy 仓库提交权限。
当您在一个特性分支中有一组“准备就绪”的更改,可以用于 NumPy 的 main 或 maintenance 分支时,您可以按以下方式将其推送到 upstream
首先,合并或变基到目标分支。
仅当提交很少且不相关时,才优先选择变基
git fetch upstream git rebase upstream/main
请参阅 在主分支上变基。
如果所有提交都相关,则创建一个合并提交
git fetch upstream git merge --no-ff upstream/main
检查您将要推送的内容是否合理
git log -p upstream/main.. git log --oneline --graph
推送到 upstream
git push upstream my-feature-branch:main
注意
通常最好使用 -n 标志运行 git push 来首先检查您是否要将所需更改推送到正确的位置。