1.Code 代码部分
2.Issues 提交BUG问题的地方
3.Pull requests 修改别人的代码并返还
Pull Request是用户修改代码后向对方仓库发送采纳的请求功能，也是GitHub的核心功能，正式因为有了这个功能，
才会让众多开发者轻松地加入到开源开发的队伍中来。
步骤：
1)先 fork 别人的仓库，相当于拷贝一份; (fork拷贝别人的代码)
2)clone 到本地分支，做一些 bug fix (修复bug)
3)发起 pull request 给原仓库，让他看到你修改的 bug
4)原仓库 review 这个 bug，如果是正确的话，就会 merge 到他自己的项目中 (review审查,merge合并)
5)至此，整个 pull request 的过程就结束了。
4.Project 项目交互部分
1)项目代码交互
2)项目bug问题交互
5.wiki 开放式的知识库
6.Pulse 检查项目具体情况
Pulse是体现该仓库软件开发活跃度的功能。近期该仓库创建了多少个Pull Request或Issue，
有多少人参与了这个仓库的开发等，都可以在这里一目了然。根据这个页面，用户可以判断目前这个软件是否正在被积极开发，
或者有仓库修改权限的人是否在认真地进行BUG修正等维护工作。在GitHub选软件时，它可以作为一个重要的衡量标准。
7.Graphs 图表
1)Contributore(用户贡献信息)
在Contributore的4种图表中，我们可以看到每个用户在相应日期中发送提交、添加代码、删除代码的大致数量，
从这里我们可以看到该仓库的代码主要由哪些人编写。而且，还可以通过图标分析处该软件大幅修改阶段和稳定维护阶段
的相应时期。
2)Traffic(通信)
含有代码下载等信息
3)commits(代码提交信息)
Commits Activity中显示了一年内（52周）每周收到的提交的大致数量。通过左箭头和右箭头移动，还可以查看每天
的提交数量，下面的曲线相应的跟着变动。判断某个仓库是否在积极的更新时，这部分是一个重要的指标。
4)Code Frequency(频率)
Code Frequency中显示了该仓库中代码行数的增加量和删除量。基线以上绿色线条表示增加的代码数量，
基线以下红色线条表示删除的代码数量。一款优秀的软件并不会一味的增加代码，在经过重构之后，代码量往往会降低。
5)Punch card(穿孔卡片)
从Punch card的图中可以直观地掌握一周内每天何时收到的提交最多，黑色圆圈越大提交越频繁。
仓库的关键人物通常会出现在提交频率最高的时间段，因此，用户发送的Pull Request最有可能在这段时间内被处理。
大致了解时间规律，将有助于大家把握好发送Pull Request以及等待回复的时间点。
6)Network(分支网络)
以图表形式显示包括克隆仓库在内的所有分支的提交。可以直观的看出每个人做了多少工作。将鼠标移到图中的点上，
可以查看相应的参考内容。
7)Members(成员)
这个树型列表展示的拥有该仓库权限的、Fork并提交过代码的用户。层级关系表示的是组织下的成员。
8)Dependents(关联)
8.Settings 设置
在这里可以对仓库进行任何设置。用户必须有更改权限的设置才能看到这个页面。
1)Settings
在这里可以修改仓库名称，设置显示仓库URL时默认显示的分支。这个默认分支同时也是可以创建Pull Request时的默认值，
如果各位的主分支不是master分支，建议更改这一设置。
2)Features
这里可以更改Wiki和Issue的相关设置。如果想关闭某些功能，只要取消勾选相应复选框即可，该功能就会从菜单中移除，
无法使用。
3)Merge Button
这里可以设置合并代码按钮的合并方式，第一个选项是是否允许合并后再提交，默认是允许的；第二个选项是指是否允许压缩、
压碎提交
4)GitHub Pages
GitHub有一个名为GitHub Pages的仓库，用户可以利用该仓库中资料创建WEB页面，用来发布仓库中软件的相关信息
如果已经创建过Pages，则会显示相应的URL。点击Automatic Page Generator即可以自动创建GitHub Pages。
5)Danger Zone
这里是一些需要格外留意的设置，在这里用户可以将仓库改为私有或是变更仓库的所有者，甚至删除仓库本身。
这些设置有可能影响到其他人，在变更时一定要谨慎。