Github 使用介绍
相关网站
基础使用
Fork仓库
点击仓库右上角的Fork后，选择需要放到的org即可。
保证代码同步
git clone这个fork的项目
git clone <fork url>
git remote add <name> <ori url>
# 更新 "指定" remote 底下的分支
git fetch <name> <branch>
# 更新多个 remote 底下的分支
git remote update
## 或者
git fetch --all
# 保持同步
git pull --rebase <remote> <branch>
## 等同于以下两条命令
git fetch <remote> <branch>
git rebase <remote>/<branch>
pull request
Github上的许多开源项目使用pull request进行代码review和讨论。
pull request有2种类型：
- 对一个
forked仓库进行pull request - 对一个仓库里的分支进行
pull request
issue
github使用issue追踪需求和修复bug。
- 管理人创建issue模版
- 使用者可以根据模版提交
issue issue可以添加tag、分配、订阅等动作
创建分支
贡献者创建一个自己的新分支，在该分支上进行操作，最后通过pull request方式合并到主分支上。命令如下：
git checkout -b feature_x
git push --set-upstream origin <分支名>
提交commit
- commit 格式
<Header> # 必需的
<Body> # 可选
<Footer> # 可选
- commit 示例
feaute: func ..
More abcdefs ... sdf fatures
very good
- feature 1
- feature 1
close #1661
- Header格式
<type>: <subject>
type类别：
- feat：新功能（feature）
- fix：修补bug
- doc：文档（documentation）
- style：格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
subject是 commit 目的的简短描述。以动词开头，使用第一人称现在时，比如改变，而不是改变了。结尾不加句号（。）
- Body格式
Body 部分是对本次 commit 的详细描述，可以分成多行。
- Footer
Footer 部分应该包含：
- 关闭issue，格式为：
... #<issue id>
review 相关缩写
Github 上的码农们在 code review 信息：
- PR: Pull Request. 拉取请求，给其他项目提交代码
- LGTM: Looks Good To Me. 朕知道了代码已经过 review，可以合并
- SGTM: Sounds Good To Me. 和上面那句意思差不多，也是已经通过了 review 的意思
- WIP: Work In Progress. 传说中提 PR 的最佳实践是，如果你有个改动很大的 PR，可以在写了一部分的情况下先提交，但是在标题里写上 WIP，以告诉项目维护者这个功能还未完成，方便维护者提前 review 部分提交的代码。
- PTAL: Please Take A Look. 用来提示别人来看一下
- TBR: To Be Reviewed. 提示维护者进行 review
- TL;DR: Too Long; Didn’t Read. 太长懒得看。也有很多文档在做简略描述之前会写这么一句
- TBD: To Be Done(or Defined/Discussed/Decided/Determined). 根据语境不同意义有所区别，但一般都是还没搞定的意思