目前使用的Fork工作流

[sunyongjian]

fork工作流

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

工作流程

• developer fork 正式仓库(tob/sls-admin-frontend
  )到自己的账户下

• clone 自己的仓库到本地

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

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

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

• 利用 pull request 提交到主仓库

• 同步主仓库代码

  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，注意点

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

  git push origin develop -f
  

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

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

为什么这样做

• 利用 pull request， 同伴之间相互审代码，做简单的 code review

  常见的变量名，代码规范问题，在 pr 里及时做 comment 指出

• 主仓库的安全性更高。 master，develop

• 更容易规范，相互约束

• 减少主仓库不必要的分支。 因为分支都到你自己的仓库去了

• 跟传统的分支操作类似，容易上手

劣势

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