愿你坚持不懈,努力进步,进阶成自己理想的人

—— 2017.09, 写给3年后的自己

使用rebase的Git工作流

Git是目前最为强大的代码版本管理工具,被开源社区和各大公司所广泛使用。使用Git进行团队协作开发是很便利的一件事情,但是在多人协作的过程中,我们也会面临如何运用好Git的问题。这种情况下,就出现了各种各样的Git Workflow,而本文将介绍一种基于rebase的工作流,这种工作流也是目前开源社区所比较推崇的做法,了解了这种工作流之后可以更好地优化对git的使用、对代码的管理

一、Rebase和Squash

1、Rebase是什么,为什么使用Rebase

rebase是能够将我们对代码的更改从一个分支集成到另一个分支中的git命令之一(另一个命令是Merge)。使用rebase的一个风险在于,它会改写commit历史,如果操作不当那么会是一种破坏性的操作。

风险总是与利益并存的,使用rebase也好处良多,体现在于:

  • 能够保持提交记录的清爽,不带来额外的提交历史(而使用merge会生成一条mergecommit
  • 能够保持commit线的线性,保持成一条直线,从而能够容易地看出代码是如何推进的

2、Squash是什么,为什么使用Squash

rebase可以运行在“交互(interactive)”模式下,交互模式下的rebase操作允许我们将多次commit进行压缩,从而合并成更少的、甚至单一的一次提交。

之所以这么做,是因为在我们有很多commit时,在最终合并到master分支时,这些commit就都会进入mastercommit历史中,那么这会导致master中的提交历史不那么可读。

举个例子,假设我们为某个feature进行了多次commit,每次commit都只是做了一点点的更新,那么commit历史看起来会像是这样:

e94d2fb (HEAD -> feat-china) feat: Add Shenzhen
81d2258 feat: Add Guangzhou
1525479 feat: Add Shanghai
e8021a2 feat: Add Beijing
40d9fc0 feat: Add headline
ce9657d (upstream/master, origin/master, origin/HEAD, master) feat: i18n (#1)
ab15f4f feat(i18n): Add support for Japanese
a39b290 feat: Add new headline
4774815 Initial commit

我们之所以频繁地提交commit,是为了能够及时地存档,以便能够在需要的时候方便地回滚代码。但是为了修复特定问题、开发某个特性的多次小提交,其实是仅仅在当前开发上下文中有意义的,可能我们为此提交了十几个commit,但是对于其他同事而言,他们可能就只想知道我们这次做了什么事情。那么通过Squash这个操作,我们就能够将这些小commit进行合并,组成一个有意义的commit。以下是用了Squash后的结果:

c27766b (Head -> feat-china) feat: show first-tier cities of China
4774815 (master) Initial commit


二、基本法则

在这套工作流中,有一些重要的法则,即:

  • 在fork的仓库上拉分支 每个贡献者都应该fork代码仓库并且在该fork出的仓库上进行开发。通过fork仓库,就可以拥有独立的工作空间,从而可以放心大胆地进行开发、修改等,对于多人开发而言,还无需事先获得分支权限也能继续开发(Tips:其实并不建议多人在同一个分支上进行开发,因为这样子很容易导致合并冲突,如果某个feature需要不止一个人去开发,相比只拉一个feature分支,把大的feature拆分为小的可独立工作单元其实是一种更好的实践)
  • 禁止对一个多人协作的分支进行rebase 这一点非常重要,贡献者只能对自己fork仓库的分支进行rebase,这是因为rebase会改写commit历史,是比较危险的一种操作,只有对自己fork仓库的分支进行rebase,才不会有任何问题


三、工作角色

在这套工作流中,涉及两个角色:

  • Maintainer(维护者):维护者拥有仓库的写权限,他们可对Pull Request进行Review来决定通过或者拒绝,并且能创建Git Tag用于发布
  • Contributor(贡献者):贡献者拥有仓库的读和fork权限,可以查看和创建issue,也可以提交Pull Request。贡献者也负责解决合并冲突,此外贡献者仅能推送分支到自己fork的仓库里


四、准备工作

在开始这套工作流之前,我们需要先做一些起始步骤。首先,需要先fork项目仓库(通常原项目仓库惯称为upstream,上游仓库);然后,在本地clone这个fork后的仓库(与此对应的远程仓库惯称为origin);之后,在本地的remote记录中添加这个upstream仓库,具体步骤如下:

  1. Fork上游仓库,如在Github中可以点击右上角的“Fork”按钮:
  2. 在本地clone这个fork后的仓库,如:
$ git clone git@github.com:RuphiLau/playgit.git
$ cd playgit
  1. 添加上游仓库
$ git remote add upstream git@github.com:trialground/playgit.git
  1. 确认信息:通过git remote -v确认我们是否成功进行了配置,正常而言需要显示两组记录(一组origin,一组upstream),如:
origin git@github.com:RuphiLau/playgit.git (fetch)
origin git@github.com:RuphiLau/playgit.git (push)
upstream git@github.com:trialground/playgit.git (fetch)
upstream git@github.com:trialground/playgit.git (push)


五、工作流

好了,说了这么多前置知识,总算应该开始进入正题了。在工作流中,建议所提交的代码是关联一个user story(用户故事)或者一个issue的,可以和一些外部系统相关联(如JIRAVersionOne),本套工作流的步骤总结如下:

  • 第一步: fetch上游仓库的更新
  • 第二步:upstream/master分支和本地master合并
  • 第三步: 在本地新建分支
  • 第四步: 写代码、提交代码
  • 第五步: 再次fetch上游仓库的更新(以同步在拉取分支之后upstream/master中更新的内容)
  • 第六步: 对分支基于upstream/master进行rebasesquash,并且解决合并冲突(如果有)
  • 第七步: 推送分支
  • 第八步: 发起一个Pull Request,进行Code ReviewCode Review通过后,合并到master,此后可以删除本地分支

以下是具体的细节:

1、fetch上游仓库的更新

我们开发时,应当基于最新版本的代码库进行开发。国际惯例,我们一般将原始被fork的那个仓库成为upstream仓库(上游仓库),通过fetch命令,我们可以将upstream中的内容获取下来存在本地,即执行:

$ git fetch upstream

示例流程图:

ORIGIN:
 master: A->B

UPSTREAM:
 master: A->B->C

LOCAL:
          master: A->B
   origin/master: A->B
 upstream/master: A->B->C   # 获取结果

2、将upstream/master分支和本地master合并

一般情况下,我们都是先拉取远程分支,然后基于此创建本地新分支,这样子就能够拥有最新的代码。不过在创建本地新分支前,我们可以先执行以下命令:

$ git checkout master
$ git merge upstream/master

这样子将会执行一个快速合并(Fast-Forward)来让masterupstream/master指向同一个提交,示例图:

ORIGIN:
 master: A->B

UPSTREAM:
 master: A->B->C

LOCAL:
          master: A->B->C   # 新增了C
   origin/master: A->B
 upstream/master: A->B->C

3、创建本地新分支

现在master分支是最新的了,因此我们可以基于此来拉新分支:

$ git checkout -b feat-xyz

示例图:

ORIGIN:
 master: A->B

UPSTREAM:
 master: A->B->C

LOCAL:
          master: A->B->C
   origin/master: A->B
 upstream/master: A->B->C
        feat-xyz: A->B->C   # 新增了 feat-xyz 分支

4、编写代码、提交代码

这一步就是开发的主要步骤了,开发过程中我们可以时不时地提交commit(当然也要确保commit是有意义的),示例图:

ORIGIN:
 master: A->B

UPSTREAM:
 master: A->B->C

LOCAL:
          master: A->B->C
   origin/master: A->B
 upstream/master: A->B->C
        feat-xyz: A->B->C->D->E->F   # 新增了 D、E、F 三次 commit

5、再次拉取代码

编码结束后,在发起一个Pull Request合并上游仓库的master分支之前,我们需要抓取一些upstream里的新提交记录(这是因为对于原仓库而言,我们不是唯一的一个开发者),示例图:

ORIGIN:
 master: A->B

UPSTREAM:
 master: A->B->C->C2->C3   # 其他人新提交了 C2、C3 两次 commit

LOCAL:
          master: A->B->C
   origin/master: A->B
 upstream/master: A->B->C
        feat-xyz: A->B->C->D->E->F

为了保持和upstream/master的同步,我们需要使用git fetch

$ git fetch upstream

拉取之后,示例图:

LOCAL:
          master: A->B->C
   origin/master: A->B
 upstream/master: A->B->C->C2->C3   # 拉取结果
        feat-xyz: A->B->C->D->E->F

6、Rebase和Squash

rebase会改变原commit所基于的分支(简称变基),并且创建带着新SHA-1哈希的新commit(与此同时会保留原有提交信息)。而squash会将多个commit压缩为一个新的commit(也可以是多个commit)并且带上新的SHA-1哈希值。通常情况下,我们会想要对目标合并分支进行rebase,当最终创建Pull Request的时候,这个rebasesquash后的分支就会从origin仓库的分支进入到upstream仓库的master分支里,所以我们需要rebase upstream/master,为了执行squash操作,我们需要运行交互模式的rebase,如下:

$ git rebase --interactive upstream/master

这将会打开默认的编辑器,然后呈现将被rebasecommit列表,如:

pick 40d9fc0 feat: Add headline
pick e8021a2 feat: Add Beijing
pick 1525479 feat: Add Shanghai
pick 81d2258 feat: Add Guangzhou
pick e94d2fb feat: Add Shenzhen

# Rebase ce9657d..e94d2fb onto ce9657d (5 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

开头即为commit列表,而#中的内容则是对一些操作的解释。commit列表中列出了从旧到新的每次commit,然后我们可以使用说明里的命令选择对这些commit执行怎样的一个操作,当我们操作完了后,可以保存文件然后退出编辑器。这之后,rebase就会基于所选择的命令进行处理。
rebase过程中,可能会有合并冲突(比如你和upstream/master里都修改了同个文件的同一部分),那么这时候,需要手动解决冲突,步骤如下:

  • 通过git status查看哪些文件发生了冲突
  • 手动解决冲突
  • 运行git add来暂存文件
  • 运行git rebase --continue来继续合并过程(不需要用git commit来解决合并冲突)

rebase之后的示例图如下:

ORIGIN:
 master: A->B

UPSTREAM:
 master: A->B->C->C2->C3

LOCAL:
          master: A->B->C
   origin/master: A->B
 upstream/master: A->B->C->C2->C3
        feat-xyz: A->B->C->C2->C3->D->E->F   # Rebase结果

如果我们还执行了squash操作,那么这多次的commit会被压缩,git会提示我们输入commit message来作为这次压缩后的commit message,所以我们通常需要让这条message能够概括多次commit的内容,示例图:

LOCAL:
          master: A->B->C
   origin/master: A->B
 upstream/master: A->B->C->C2->C3
        feat-xyz: A->B->C->C2->C3->DEF   # Squash结果

7、推送分支

为了创建一个Pull Request,我们需要将分支推送到origin仓库,可以运行:

$ git push --set-upstream origin feat-china

如果你已经推送过你的分支了,并且想要更新它,那么以上的命令会执行失败。这是因此rebase改写了commit历史,所以不再有一个公共的commit,因此需要使用--force选项来告诉git放弃并覆盖远程分支,即:

$ git push --force origin feat-china

Tips: 以上也是为什么我们要在fork分支上独立写代码的主要原因

8、发起一个Pull Request

到这里,是时候对上游仓库的master分支发起一个来自origin仓库feat-china分支的PR了,通常在我们push之后,在github中可以看到如下图所示:

这时候点击“Compare && pull request”便可进入发起PR的流程

ORIGIN:
   master: A->B
 feat-xyz: A->B->C->C2->C3->DEF  ----
                                    | Pull Request
UPSTREAM:                           | 
 master: A->B->C->C2->C3        <----

进入PR创建页面后,我们可以填写对这个PR的描述信息,然后点击Create pull request便可成功发起PR

我们可以通过填写Reviewers邀请同事进行Code Review(与此同时,还可以通过CI处理一些流程,比如校验代码格式、判断是否已经Review通过,必须完成这项步骤才能合并代码):

CI(如果有)通过和Code Review通过后,我们便可以点击Squash and merge或者Rebase and merge来合并代码到master(这里我们推荐Squash and merge,可以压缩多次commit为一次):

此后,维护者接受PR,代码就会被自动合并到master分支里,并且关闭该PR。然后,我们也可以做一些后期清理工作:删除本地分支和远程分支(如feat-chinaorigin/feat-china),可以执行如下命令:

$ git branch -D feat-china
$ git push origin --delete feat-china

最终效果为:

ORIGIN:
   master: A->B

UPSTREAM:
 master: A->B->C->C2->C3->DEF

LOCAL:
          master: A->B->C
   origin/master: A->B
 upstream/master: A->B->C->C2->C3->DEF


六、成果

现在,让我们来看一下这个工作流带来的成果,以下是以上步骤完成后,所呈现出的一个commit历史:

怎么样,是不是又干净又清爽呢?I do believe that you'll enjoy it !


参考资料