Forking 工作流

fork 操作是在个人远程仓库新建一份目标远程仓库的副本，流程如下：

比如在 GitHub 上操作时，在项目的主页点击 fork 按钮（页面右上角），即可拷贝该目标远程仓库。

假设开发者 A 拥有一个远程仓库，如果开发者 B 也想参与 A 项目的开发，B 可以 fork 一份 A 的远程仓库到自己的 GitHub 账号下。后续 B 可以在自己的项目进行开发，开发完成后，B 可以给 A 提交一个 PR。这时候 A 会收到通知，得知有新的 PR 被提交，A 会去查看 PR 并 code review。如果有问题，A 会直接在 PR 页面提交评论，B 看到评论后会做进一步的修改。最后 A 通过 B 的 PR 请求，将代码合并进了 A 的仓库。这样就完成了 A 代码仓库新特性的开发。如果有其他开发者想给 A 贡献代码，也会执行相同的操作。

操作流程

1、Fork 远程仓库导自己账号下

访问 https://github.com/stoneatom/stonedb.git
点击Fork 克隆项目到自己的项目仓库

克隆后的仓库地址为：
https://github.com/zsp108/stonedb.git

2、克隆 fork 的代码仓库导本地

$ git clone https://github.com/zsp108/stonedb.git
$ cd stonedb
$ git remote add upstream https://github.com/stoneatom/stonedb.git
$ git remote set-url --push upstream no_push   # Never push to upstream master
$ git remote -v # Confirm that your remotes make sense
origin  https://github.com/zsp108/stonedb.git (fetch)
origin  https://github.com/zsp108/stonedb.git (push)
upstream        https://github.com/stoneatom/stonedb.git (fetch)
upstream        no_push (push)

3、创建功能或修复分支

创建前需要保证本地仓库master 分支为最新状态，跟 upstream master 分支一致，然后每次开发新功能或者修复bug都必须基于主分支创建一个开发分支，在开发分支上进行操作

$ git fetch upstream
$ git checkout stonedb-5.7-dev
$ git rebase upstream/stonedb-5.7-dev

创建新功能或者修复分支

$ git checkout -b fix/mtr336

4、提交commit

在 fix/mtr336 分支上开发代码，开发完代码后，提交 commit。提交commit 前最好先执行下fetch 更新下本地代码，操作参考如下，commit记录需要符合commit记录格式

$ git fetch upstream # commit 前需要再次同步 fix 跟 upstream/master
$ git rebase upstream/stonedb-5.7-dev
$ git add 
$ git status
$ git commit

commit记录

（这个操作可以省略）分支开发完成后，可能会有一堆 commit，但是合并到主干时，我们往往希望只有一个（或最多两三个）commit，这可以使功能修改都放在一个或几个 commit 中，便于后面的阅读和维护。这个时候，我们可以用 git rebase 来合并和修改我们的 commit，操作如下：

$ git rebase -i origin/stonedb-5.7-dev

具体commit 合并方式很多，可以参考下

https://stoneatom.yuque.com/staff-ft8n1u/qfqtnb/qbl45c#XkRA2

5、push 功能分支到个人远程仓库

在完成了开发，并 commit 后，需要将功能分支 push 到个人远程代码仓库，代码如下：

$ git push -f origin fix/mtr336

6、在个人远程仓库页面创建 pull request。

提交到远程仓库以后，我们就可以创建 pull request，然后请求 reviewers 进行代码 review，确认后合并到 master。这里要注意，创建 pull request 时，base 通常选择目标远程仓库的 master 分支。

(之前忘记截图了，pr界面类似下图，下图是已经提过pr了，所以按钮是view pull request,没有提过pr的话是create pull request)

点击创建PR之后，跳转到PR信息填写界面，PR标题和commit 一样需要符合 commit记录格式 标准，填写好关联的issues ID和基本信息后挑选reviewers 人后提交等待mergify和reviewer完成即可，填写后的界面如下图所示

commit 记录格式

Valid format:

fix(vc): fix sth..... (#3306)
^         ---------  ----
|         |            |
|         +            +-> you issue id.
|         |
|         +-> Summary in present tense.
|
+-------> Type: feat, fix, docs, workflow, style, refactor, test, website, chore

Valid types:

feat: 		new feature for stonedb
fix: 			bug fix for stonedb
docs: 		changes to the documentation
workflow: ci/cd in .github
refactor: refactoring production code, eg. renaming a variable
style: 		formatting, missing semi colons, etc; no production code change
test: 		adding missing tests, refactoring tests; no production code change website
chore: 	updating grunt tasks etc; no production code change