分支命名规则：
项目代码分为3个特性分支，命名规则为：
开发版本：特性名_master
测试版本：特性名_test_branch
正式版本：特性名_release_branch
注：如果是默认项目，特性名可以省略。否则需要加上对应的特性名称，比如当前在当前项目基础上给某单位/组织/地域开发项目时，特性名前缀为对应的拼音，首字母大写，比如给西安开发某项目，分支名称为Xian_**_**。
Fork仓库，本地修改后提交PR
Fork之后，个人名下就可以看到Fork出来的仓库了，对应的分支也能看到：
找到地址，clone代码下来：
在默认的master分支，修改Fork出来的本地文件：
Commit后，push刚才的修改到OSChina个人名下的master分支：
刷新OSChina个人名下仓库，可以看到对应的ReadMe文件已经修改了，点击Pull Request：
制定源分支、目标分支、代码审查人员，
PR提交给组织了，上面我们指定了“刘超”审查代码，“卞晓辉”进行测试。可以看到状态是未审核，未测试。
对应的人员会收到审查和测试通知，如下：
审查和测试通过后，可以接受代码合并了，如下：
合并后，如果还有一次反悔的机会，慎重使用：
可以看到对应的修改已经更新到主仓库上（XAVito/HelloWorld）。如下：
Fork仓库同步主仓库的最新代码
主仓库主分支更新了内容，如下：
Fork仓库同步主仓库的更新：
更新后查看差异（注意当前在Fork仓库的master分支上），有如下两种方式：
测试在Fork出来的仓库master分支做增量修改并提交（预期会产生冲突）。如下：
试用merge，产生冲突，如下：
解决冲突，并提交代码到Fork仓库：
但与此同时主仓库也前进了，如下：
Fork仓库提交更新到主仓库（PR审查代码勾选上），提交PR后，主仓库收到更新通知了：：
审查没有问题，通过，发现和主仓库的修改有冲突了，如下：
好办，解决冲突：
注：对于冲突的代码，代码审核人员必须要大家解决冲突，对于存在冲突的PR，关闭PR并评论。
进一步学习
合并最近的多次提交
参考地址
变基
分支是很让人讨厌的，因为代码提交历史不够整洁。也有办法让他归到一个分支上去，使用rebase。方法请参考【变基】。
