维护者工作流程

本页面是为维护者准备的 — 我们这些将自己的或他人的更改合并到上游仓库的人。

既然你是维护者，你对 开发工作流程 中的基本内容了如指掌。

在 将您的仓库链接到上游仓库 中的指令添加了一个对上游仓库具有只读访问权限的远程。作为维护者，您拥有读写访问权限。

给你的上游远程仓库起一个吓人的名字是好的，这样可以提醒你它是一个读写远程仓库:

git remote add upstream-rw git@github.com:scikit-image/scikit-image.git
git fetch upstream-rw

整合变更

假设你有一些需要进入主干 (upstream-rw/main) 的更改。

这些更改在你当前所在的某个分支中。例如，你正在查看某人的更改，如下所示:

git remote add someone https://github.com/someone/scikit-image.git
git fetch someone
git branch cool-feature --track someone/cool-feature
git checkout cool-feature

所以现在你在包含要合并到上游的更改的分支上。本节的其余部分假设你在这个分支上。

几次提交

如果只有少量提交，考虑变基到上游:

# Fetch upstream changes
git fetch upstream-rw
# rebase
git rebase upstream-rw/main

记住，如果你进行了变基并推送，你将需要手动关闭任何GitHub的拉取请求，因为GitHub将无法检测到这些更改已经被合并。

一系列长时间的提交

如果有更长的一系列相关提交，考虑进行合并:

git fetch upstream-rw
git merge --no-ff upstream-rw/main

合并将被GitHub检测到，并应自动关闭任何相关的拉取请求。

注意上面的 --no-ff。这会强制 git 创建一个合并提交，而不是进行快速合并，这样这些提交集会从主干分支出来，然后通过合并重新加入主历史，而不是直接在主干之上提交。

查看历史

现在，无论哪种情况，你都应该检查历史记录是否合理，并且你拥有正确的提交:

git log --oneline --graph
git log -p upstream-rw/main..

上面的第一行只是以紧凑的方式显示了历史记录，用历史图的文本表示。第二行显示了提交日志，排除了可以从主干（upstream-rw/main）到达的提交，并包括了可以从当前HEAD（通过末尾的``..``隐含）到达的提交。因此，它显示了与主干相比，这个分支独有的提交。``-p``选项以补丁形式显示这些提交的差异。

推送到主干

git push upstream-rw my-new-feature:main

这将把本仓库中的 my-new-feature 分支推送到 upstream-rw 仓库的 main 分支。