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，这至少是迈向开源的第一步。可能有时我们会感觉自己水平很菜，但其实每个人都是从菜鸟到大牛逐步迈进的。

我总是告诫自己：“虽然我很菜，但我也要菜出特色。”

分享此处与君共勉！！

来源：oschina

链接：https://my.oschina.net/u/4416479/blog/4282368