目前使用的 Fork 工作流

Question

更多的出现在开源项目上，开放 developer 随意提交 pr 的权限，但是合并由正式仓库的管理员操作。

工作流程

1、developer fork 正式仓库（tob/sls-admin-frontend）到自己的账户下

2、clone 自己的仓库到本地

3、添加一个 upstream 更新主仓库的代码
因为你自己远程仓库建立的别名是 origin，还需要一个主仓库的，通常叫 upstream （上游）

git remote add upstream git@code.smartstudy.com:tob/sls-admin-frontend.git

4、在自己仓库正常开发，commit，push

5、利用 pull request 提交到主仓库

6、同步主仓库代码

git pull upstream develop

但是我们建议使用 rebase

1. git fetch upstream develop
2. git rebase upstream/develop
3. git commit
4. git push origin develop

或者

git pull upstream develop --rebase

因为你自己的仓库，可以随意操作，可以随意使用 rebase 合代码，以及更改提交记录。
使用rebase的好处是治疗洁癖患者

合并前：

         A---B---C  remotes/origin/master
        /
   D---E---F---G  master

使用 merge 合并后：

       A---B---C   remotes/origin/master
       /       
  D---E---F--- G---H master

graph 会多出一根线，多了一个 H 的提交，所以分支多了 merge 多了，graph 没法看

使用 rebase 合并：

       remotes/origin/master
          |
  D---E---A---B---C---F'---G'  master

简单来说，它会把本地新的提交移动到 remote 提交的后面。具体就是会先找出本地跟 remote 分叉之前的一个点，把本地的新提交先缓存起来，再把 remote 的提交并入，最后把本地的 commit 提交。当你并入 remote 的时候，由于 commit 历史改成了从 C 开始，所以并入 remote 只是在原来基础上增加几个新的提交，保持 commit 的简洁。

PS 注意点

1、强制提交
rebase 完 upstream 的提交，由于本地 commit 跟你 remote 仓库的提交历史不同，出现分叉，需要强制提交。 -- force

git push origin develop -f

2、什么时候别用 rebase
千万不要在主仓库做 rebase 合并代码的操作。只要这个分支有其他人在用，就不要用 rebase。

3、处理冲突
提 pull request 之前最好先同步主仓库的代码。也就是 rebase 一下 upstream 上的代码。提完 pr 出现冲突，本地拉一下主仓库的代码，解决冲突，就好了。pr 已经提出，主要不合并，可以一直往上面commit

为什么这样做

• 利用 pull request， 同伴之间相互审代码，做简单的 code review，常见的变量名，代码规范问题，在 pr 里及时做 comment 指出
• 主仓库的安全性更高。 master，develop
• 更容易规范，相互约束
• 减少主仓库不必要的分支。 因为分支都到你自己的仓库去了
• 跟传统的分支操作类似，容易上手

劣势

• 操作繁琐
• 每个人一个仓库
• 更适用于十几个以上开发者的项目