[TOC]

项目代码分为3个特性分支，命名规则为： 开发版本：特性名_master 测试版本：特性名_test_branch 正式版本：特性名_release_branch 注：如果是默认项目，特性名可以省略。否则需要加上对应的特性名称，比如当前在当前项目基础上给某单位/组织/地域开发项目时，特性名前缀为对应的拼音，首字母大写，比如给西安开发某项目，分支名称为Xian******。

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。方法请参考【变基】。