选择社区项目进行 Fork，开发工作应当放在自己的仓库中，个人仓库的 master 分支负责与上游仓库进行同步。
Clone 个人仓库的项目，在本地开发中，可以同时添加上游仓库源；修改代码时，从最新的 master checkout 到新的临时分支（eg：tmp-branch），在该分支上进行开发，之后 push 到远程个人仓库的一个临时分支（可以直接和本地分支名相同）上。
1 | |
此时进入上游仓库，可以发现来自个人仓库临时分支的 pull request 提示，点击并填写提交信息，发起合并请求。自动化测试工具通过后，就只需等待社区人员审查，交流通过后便可以将自己的修改合进原项目。此时可以直接删除个人仓库中的临时分支。
下次修改前需要先将个人仓库的 master 分支与上游仓库进行同步。
一般在社区的首次 PR 请求，会要求贡献者签署 CLA，按照相应的提示操作即可。一些社区也会提供
playground项目，可以在该项目中练习 PR 的流程，并完成签署 CLA。需要注意的是，提交 PR 请求，通过后会根据 PR 的提交信息创建一个新的 commit 点，PR 中个人分支上的多条新 commit 点并不会出现在上游仓库的主分支上。
需要一定的规范来约束开发人员的 commit 信息格式，其中，Angular提交信息规范是一种非常受开发人员欢迎的 commit 信息规范。
每条 commit message 都由 header、body 和 footer 组成。而 header 包括 type、scope 和 subject：
1 | |
type 必须是以下值之一：
subject 要求：
change，而不是 changed 或 changes借助 commitizen 可以方便地规范输入 commit 信息。
1 | |
此时，可以使用 cz 命令代替 git commit，进行规范化 commit 提交。
| 缩写 | 英文 | 中文 |
|---|---|---|
| PR | Pull request | 拉取请求 |
| BTW | By the way | 顺便说一句 |
| WIP | Work in progress, do not merge yet | 进行中暂时不要合并 |
| LGTM | Looks good to me | 在我看来很好 |
| PTAL | Please take a look | 帮我看下，请别人 review 自己的 PR |
| CC | Carbon copy | 抄送 |
| FYI | For your information | 供你参考 |
| RFC | Request for comments | 我觉得这个想法很好, 我们来一起讨论下 |
| IIRC | If I recall correctly | 如果我没记错 |
| ACK | Acknowledgement | 认可 |
| NACK/NAK | Negative acknowledgement | 不认可 |
参考：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。