Fork项目

如果要参与某个项目，但是并没有推送权限，可以对该项目“派生”。Github会在你的空间创建完全属于你的项目副本，并且对你有推送权限。

开发者可以将修改推送到fork的项目中，并通过创建合并请求（Pull Request）让改动进入源版本库。

在创建合并请求之后，将会开启一个可供审查代码的版块，项目的拥有者和贡献者将再次讨论、修改，知道项目拥有者对其感到满意，然后会将这些修改合并到版本库。

将合并请求制作成补丁

大多数GitHub项目将合并请求的分支当做对改动的交流方式，并将变更集合起来统一进行合并。

维护项目

首先是创建新的版本库，来分享我们的项目。

如果你想与他人合作，并想给他们提交的权限，就需要把他们添加为“Collaborators”。

管理合并请求

合并请求可以来自仓库副本的一个分支，或者同一个仓库的另一个分支。唯一的区别是，fork过来的通常是和你不能相互推送的人，而内部的推送通常都可以互相访问。

假设，tonychacon创建fade的Arduino项目。当有人修改你的代码，它会向你发送一个合并请求。

这个邮件会给出你一个小的变动的统计结果：改变的文件和改变了多少的列表。

上面图片有提到合并远程分支的简单方式git pull <url> patch -l

在合并请求上进行合并

现在可以与开启合并请求的人进行会话，你既可以对某些代码添加注释，也可以对整个提交添加注释，或对整个合并请求添加注释。

一旦代码符合你的额要求，就可以将其合并进来，既可以将代码拉渠道本地进行合并，也可以使用git pull <url> <branch> ，或者是将fork添加为一个remote，然后抓取和合并。

对于琐碎的合并，可以使用GitHub网站的Merge按钮。它会做一个"non-fast-forward"合并，即使可以快进合并也会产生一个合并提交记录。

如果你决定不合并它，可以将合并请求关闭，开启合并请求的人会收到通知。

合并请求引用

GitHub在服务器上将合并请求看做一种“假分支”，默认情况下，当克隆时并不会得到它，但它们还是隐式存在的。

假设，存在版本库blink，获取该版本库所有的分支，标签和其他引用的列表

$ git ls-remote https://github.com/schacon/blink
10d539600d86723087810ec636870a504f4fee4d    HEAD
10d539600d86723087810ec636870a504f4fee4d    refs/heads/master
6a83107c62950be9453aac297bb0193fd743cd6e    refs/pull/1/head
afe83c2d1a70674c9505cc1d8b7d380d5e076ed3    refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1    refs/pull/2/head
15c9f4f80973a2758462ab2066b6ad9fe8dcf03d    refs/pull/2/merge
a5a7751a33b7e86c5e9bb07b26001bb17d775d1a    refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c    refs/pull/4/merge

如果你在你自己的版本库或其他你想检查的远程版本库中使用git ls-remote origin 也会显示相似的内容。

如果版本库在GitHub上有打开的合并请求，则会得到一refs/pull/开头的引用。虽然它们是分支，但因为不在refs/heads/ 中，因此在克隆时无法抓取它们。

每个合并请求有两个引用：以/head 结尾的引用指向的提交记录与合并请求分支中最后一个提交记录是同一个。

因此，如果有人开启一个合并请求，它们的分支叫做bug-fix ，指向a5a775 提交记录，但是版本库中并没有bug-fix 分支（它存在于fork中），但在本版本库有一个pull/4/head 指向a5a775 。

这意味着，我们可以很容易的拉取每一个合并请求分支而不用添加一堆remote。

$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
 * branch            refs/pull/958/head -> FETCH_HEAD

然后你可以使用git merge FETCH_HEAD 将它合并到想要测试的分支。

另一种抓取所合并请求，并保持remote更新的方式是，编辑.git/config

[remote "origin"]
    url = https://github.com/libgit2/libgit2
    fetch = +refs/heads/*:refs/remotes/origin/*

上面表示，remote上的refs/heads 下的内容在本地都放在refs/remotes/origin 。

添加另一个refspec

[remote "origin"]
    url = https://github.com/libgit2/libgit2.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

现在所有的合并请求就像本地分支一样展现。

合并请求之上的合并请求

不仅可以在master分支开启合并请求，实际上可以在任何分支开启合并请求，甚至是在合并请求上开启合并请求。

如果你看到一个合并请求在向正确的方向发展，然后向在这个合并请求上做一些修改，但是并不确定这是否合适，或者也没有推送目标分支的权限，就可以直接在合并请求上开启合并请求。

当你开启合并请求时，在页面顶端会显示你要合并到哪个分支和你从哪个分支合并而来。如果点击Edit按钮，还可以选择哪个fork

提醒和通知

GitHub内置良好的通知系统，可以在任何讨论中@项目合作者或贡献者的名字，当然也可以额提醒不再列表中的用户。

如果有人收到合并请求或问题的提醒，它们会“订阅”它。后面有心的活动发生，它们会持续收到提醒。如果你是合并请求或问题的发起方，你也会被订阅上。