github中从零到PR
概述
Github作为程序员最大交友社区，想必每个程序员都不陌生。发起一个PR应该是无数GitHub初学者的一个小心愿。下边就一步一步来讲述从零到PR的整个过程，希望能给初学者以所得。
点个Star
某日，程序员小吴闲来无事，在Github上闲逛，突然遇到了Test，一见钟情。准备搭个讪，认识一下于是点了个Star。
此处的Star:点赞。
Star之后的项目我们可以个人中心的Your stars中查看
发起Issue
小吴在使用Test项目过程发现Test项目比较实用，但是也发现了不足，比如没有README.md项目自述文件，因此小吴想给该项目加上自述文件，因此他发起了一个issue进行讨论，征求开发者意见。
此处的issue：问题，一般情况如果感觉在使用该项目过程中遇到问题或者有更好的idea都可以发起issue来进行讨论。
一般来说如果项目维护者看到你的issue之后会进行回应，讨论可行的解决方案
在github进行交流的过程中，我们常常会遇到下边这些用语，便于大家查看，整理如下图表：
| 名称 | 含义 | 中文含义 |
|---|---|---|
WIP |
Work in progress, do not merge yet | 出现在 PR 的标题中，用于提示审核人，项目正在开发中暂时不要合并 |
LGTM |
Looks good to me | 表示对提交者的赞许，鼓励他更多的参与贡献。 |
cc |
Carbon copy | 表示抄送的意思，希望某人也能收到，了解相关信息，通过 cc 后续的 @ At 出对应的成员，他可以再自己的通知中收到相关信息。 |
TL;DR |
Too Long; Didn't Read. | 太长懒得看。也有很多文档在做简略描述之前会写这么一句 |
PTAL |
Please take a look. | 帮我看下，一般都是请别人 review 自己的 PR |
DNM |
Do not merge | 不要合并 |
ACK |
acknowledgement | 我确认了或者我接受了,我承认了 |
NACK/NAK |
negative acknowledgement. | 我不同意 |
进行PR
得到回应之后，小吴便可以开始尝试Fork一个分支在本地进行开发。
此处Fork：开分支，由于本身小吴没有权限直接操作Test的仓库，因此他需要先将Test项目在自己账号下边建立起一个分支。在自己的分支下进行功能开发。
小吴接下来创建项目自述文件README.md并进行编辑
编辑完成后，发起PR。
此处PR:全程Pull Request，合并拉取请求，用以发起将自己的分支合并到主干分支的请求，请求对方将你的代码 Merge 到他的主干分支。
分支合并
项目维护者在查看提交信息后如果满足要求则会进行分支合并。合并完成之后此次PR便完成了。
然后再Test项目中的Contributors中看到vcjmhg的大名
至此一次PR便完成。
小结
希望大家在使用Github项目时，要勇敢的发起Issue，这至少是迈向开源的第一步。可能有时我们会感觉自己水平很菜，但其实每个人都是从菜鸟到大牛逐步迈进的。
我总是告诫自己：“虽然我很菜，但我也要菜出特色。”
分享此处与君共勉！！
