维修人员工作流程

此页供维护人员使用 |emdash| 我们中的那些将自己或其他人的变更合并到上游存储库中的人。

作为一个维护者，你完全掌握了 开发工作流程 .

中的说明 将存储库链接到上游回购 添加对上游回购具有只读访问权限的远程。作为一名维护人员，你有读写权限。

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

git remote add upstream-rw git@github.com:sagemath/sagenb.git
git fetch upstream-rw

整合变化

假设你有一些变化需要进入后备箱 (upstream-rw/master ）

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

git remote add someone git://github.com/someone/sagenb.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 储存库。