理解 pull request
pull request是一个request，它的目的是让别人pull你的东西。
当你想更正别人仓库里的错误时，要走一个流程：先 fork 别人的仓库，相当于拷贝一份，相信我，不会有人直接让你改修原仓库的clone 到本地分支，做一些 bug fix发起 pull request 给原仓库，让他看到你修改的 bug原仓库 review 这个 bug，如果是正确的话，就会 merge 到他自己的项目中至此，整个 pull request 的过程就结束了。
就是你想check in代码但是你没有权限，所以要求别人的意思。大家说的那么复杂干什么。
我改了你们的代码，你们拉回去看看吧 ！！！
请求对方拉你的代码。
理解 issue
GitHub 的 issue 功能，对个人而言，就如同 TODO list 。你可以把所有想要在下一步完成的工作，如 feature 添加、bug 修复等，都写成一个个的 issue ，放在上面。既可以作为提醒，也可以统一管理。另外，每一次 commit 都可以选择性的与某个 issue 关联。比如在 message 中添加 #n，就可以与第 n 个 issue 进行关联。
作者：匿蟒
链接：https://www.zhihu.com/question/22969033/answer/70835781
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
commit message title, #1
这个提交会作为一个 comment ，出现在编号为1的 issue 记录中。如果添加：close #ncloses #nclosed #nfix #nfixes #nfixed #nresolve #nresolves #nresolved #n比如commit message title, fix #n
则可以自动关闭第 n 个 issue 。issue 可以有额外的属性：Labels，标签。包括 enhancement、bug、invalid 等，表示 issue 的类型，解决的方式。除了自带的以外，也可以去自定义。Milestone，里程碑。几经修改后，它现在已经与git tag和Github release区分开来，仅仅作为issue的一个集合。通常用来表示项目的一个阶段，比如demo、release等，保护达成这些阶段需要解决的问题。有时候，也会与版本计划重合，比如v1.0、v2.0等。issue不能设置截止时间，但是milestone可以。Assignee，责任人。指定这个 issue 由谁负责来解决。充分利用这些功能，让每一个 commit 的意义更加明确，可以起到了良好的过程管理作用，使得这个 Git 库的项目进度更加显然。而且，这也是项目后期，写文档的绝佳素材。对团队而言，这就是一个协作系统。现在，很多大公司的软件研发团队协作，都是通过 JIRA 来实现的。目前也流行很多非代码的团队协作，比如 teambition、http://Tower.im、Worktile、trello 等。其实，GitHub 的 issue ，就是一个轻量级协作系统。它的 comment 支持 GitHub Flavored Markdown，可以进行内容丰富的交流。Git 本身就是分布式的代码版本控制软件，是为了程序员的协作而设计的。而 issue 的 Assignee 功能，就是这个在线协作系统的核心，足以让一群线上的开发者，一起完成一个软件项目。最后，作为一个路人，你可以通过 issue 给别人的项目提 bug 。
Issue可以用来提出question, bug, enhancement等讨论，同时他人folk提交合并后都会在Issue里面有显示。
对项目的Owner，Issues可以公开下一步的Feature，更好的听取用户建议
对用户，Issues是一个反馈平台，可以将使用时的问题发表出来，等待社区或Owner解答。
我也看到一些奇葩的用法，例如把Issues当普通论坛用。
理解 wiki
Github 上的每个项目仓库，都有三套基础设置可供使用：一个是通过 Github Pages 机制建立项目网站，后面会介绍的。另外一个就是每个项目都可以开自己的 wiki ，作为项目的知识库。第三个就是咱们今天的主角，事务卡片（ Issues ）。很多比较复杂的项目管理软件会把“报 Bug ”，“提新需求”，“其他讨论”，这些项目相关的内容分成不同的板块来进行，在 Github 这里，所有的内容就都作为事务卡片来统一管理了。