维护人员工作流程

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

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

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

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

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

整合变更

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

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

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