前言:git 的fork pr这些工作流因为一直都没有相关需求就大致了解但没有深入地操作过,但最近 pr 一个主题时直接在github上一个个文件对应着改,改了几次就产生了几次commit,而且因为以前就fork 过,导致要pull upstream 的时候因为懒而暴力地通过删除仓库再重新fork的做法来更新,想想都觉得太不优雅了

fork工作流

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

工作流程

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

  • clone 自己的仓库到本地

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

1
git remote add upstream https://github.com/被fork的仓库.git
  • 在自己仓库正常开发,commit,push

  • 利用 pull request 提交到主仓库

  • 同步主仓库代码

1
2
3
4
git pull upstream 
//或者分为两步
git fetch upstream
git merge upstream/master

但是有人高手建议使用 rebase

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

或者

1
git pull upstream develop --rebase

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

合并前:

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

使用 merge 合并后:

1
2
3
    A---B---C   remotes/origin/master
| \
D---E---F-----G---H master

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

使用 rebase 合并:

1
2
3
     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)

1
git push origin develop -f

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

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

为什么这样做

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

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

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

  • 更容易规范,相互约束

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

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

劣势

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