Github协作开发
以Chord协作开发为例。
-
先申请Github帐号
-
Fork要参加开发的项目，例如在浏览器打开chord项目Github网址 https://github.com/DigitalPlatform/chord ，点击右上角的Fork按钮，根据提示将Chord项目Fork到自己的帐号下。
-
进入到自己帐户下的Chord，复制地址，打开VS，将 fork 以后新创建在自己项目下chord克隆到本地。
-
在VS里修改代码，提交更改，并同步到自己的Chord。
- 在Github，从自己的Chord向数字平台Chord提交Pull Request，这个过程在上图中叫push推，代码经数字平台人员审核后，合并到数字平台/Chord。
- 数字平台Chord有了更新，参于者可以从数字平台Chord拉取更新到自己的chord，反向创建Pull Request即可，再在VS中，同步到本地代码。
下面再解释一下:
Fork协作方式，是一种比较松散的合作方式，具体过程如下：
合作者先 fork 一个自己的 repo。等于是从原来的 Trunk repo，复制到 GitHub 的另外一个位置，形成一个属于自己的私人 repo。然后合作者用 clone 和 push 的方式去开发、测试，修改这个自己的 repo。
合作者自己这个 repo，也可以组织一个小团队，小团队之间互相信任，属于比较密切的合作，成员都有对合作者自己这个 repo 的修改权限。
等时机成熟，一般是工作进展到一个阶段，完全收尾了，很漂亮了，然后合作者把自己的 repo 和那个 Trunk repo 之间的差异部分，提交给 Trunk repo 持有人，一个 “Pull request”。意思就是你要把这一段的成果都发送给 Trunk repo。
Trunk repo 持有人收到合作者的 PR 以后，可以开一个 branch，在本地好好测试。有可能是半个月一个月。然后终于他们认为修改都是完美的，他就用一个 merge 动作，把合作者的成果全部进入 Trunk repo 了。
如果他们测试中间发现任何问题，可能要用某种渠道和合作者沟通，然后合作者修改、测试，重新提交 PR。也就是说不是每个 PR 都会被认可的。
据说 Linux Kernel 的一些 PR 几年都得不到批准合并。他们那儿是提交 PR 的积极，都想把自己的想法纳入内核代码，但审查的人很严。
提交 PR 是任何陌生人都可以做的操作。好像没有机制拉黑一个人，不让他提交 PR。
这个提交 PR 的过程，对于公司之间合作，陌生人之间合作，非常符合管理规范，因为加入了一个自然的审核和合并动作。