维护人员工作流

这个页面是为维护人员准备的 — 我们中那些将自己或他人的更改合并到上游存储库的人。

作为一名维护人员，您完全掌握了 开发工作流 。

请参阅中的说明 将存储库链接到上游回购 添加对上游回购具有只读访问权限的遥控器。作为维护人员，您拥有读写访问权限。

让你的上游遥控器有一个可怕的名字很好，提醒你它是一个读写遥控器：：

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

整合变革

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

更改发生在您当前所在的某个分支中。例如，您正在查看的某人的更改如下：：

git remote add someone git://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/master

请记住，如果您执行并推送Rebase，您将不得不手动关闭任何GitHub拉请求，因为GitHub将无法检测到更改已被合并。

一长串的承诺

如果有一系列更长的相关提交，请考虑合并：：

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

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

请注意 --no-ff 上面。这迫使GIT进行合并提交，而不是进行快进，以便这些提交从主干分支出来，然后通过合并重新联接主历史记录，而不是看起来直接在主干之上进行。

查看历史记录

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

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

上面的第一行只是以一种简洁的方式显示了历史，并用文本表示了历史图形。第二行显示提交的日志，其中不包括可从主干访问的提交 (upstream-rw/master), and including those that can be reached from current HEAD (implied with the .. 在末尾)。因此，它显示了与主干相比，此分支独有的提交。这个 -p 选项以补丁形式显示这些提交的差异。

推送到中继线

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

这将推动 my-new-feature 在此存储库中分支到 master 分支机构在 upstream-rw 存储库。