玩转Git三剑客笔记 2

引言

整理了下之前极客时间上《玩转Git三剑客》的笔记,该课程适合入门级读者。
本文是笔记的第二部分,主要侧重的是团队协作;第一部分主要侧重的是 git 的操作

47-56 使用 Github 进行团队协作

48 选择工作流

49 分支策略

介绍了几种 merge 的工作模式。

假设现有一个库,如下:

                          master
                            |
--A---B------------C--------D
      |            BJ a  
      |____a___b___e
      |
      |___m___n__p___q 
                    SH b          

以下都是将分支 BJ merge 到 master。

Allow merge commits

将 BJ 分支合并到 master 分支,如果 git 可以处理冲突的情况下,此时会如下图:

                                master
                                  |
--A---B------------C--------D-----E
      |            BJ a          /^
      |____a___b___e____________/
      |
      |___m___n__p___q 
                    SH b          

Allow squash merging

回退到最初版本,执行: git push -f origin commit_D, 然后 merge 后:

                                master
                                  |
--A---B------------C--------D-----E
      |            BJ a          
      |____a___b___e
      |
      |___m___n__p___q 
                    SH b          

E是包含 BJ 分支的 a,b,c 的内容。

Allow rebase merging

用于产生线性分支提交,github 始终是把提交逐个挑选出来,添加到 master 分支后面。

                                          master
                                            |
--A---B------------C--------D-----E----F----G
      |            BJ a          
      |____a___b___e
      |
      |___m___n__p___q 
                    SH b          

master 分支上 E,F,G 分别对应 a,b,c(commit id相同)。

52 code review

可以在设置中对分支进行设置,比如应用到哪个分支,需要多少人review等。

53 多分支集成

在前述52分支策略的基础上,添加多分支的集成。有稍许不同之处。
先合并 BJ 再合并 SH 分支,原始分支情况如下:

                          master
                            |
--A---B------------C--------D
      |            BJ a  
      |____a___b___e
      |
      |___m___n__p___q 
                    SH b          

Allow merge commits

在合并 SH 分支的时候,需要处理 conflicts,然后 commit 再合并:

                                      master
                                        |
--A---B------------C--------D-----E-----F
      |            BJ a          ↗|    ↗
      |____a___b___e____________/  |   /
      |                             ↘ /
      |___m___n__p___q_______________|
                     b               SH

BJ 分支顺利合并到 E ,再合并 SH 时需要手动处理 conflict,此时 SH 产生新 commit,master 也产生一个新 commit。 总之 merge 的策略会使得 commit 有多个父 commit 。

Allow squash merging

合并 SH 时也需要手动处理 conflict,再继续 pull request 操作。

                                     master
                                       |
--A---B------------C--------D-----E----F
      |            BJ a           |   
      |____a___b___e              |  
      |                           | 
      |___m___n__p___q____________↓
                     b            SH        

F 包含 SH 的 m,n,p,q和手动处理的内容。

Allow rebase merging

合并 SH 分支遇到 conflicts,手动修改后,github 已经无法继续按照 rebase 的方式继续 pull request——仔细想想,SH 分支的内容由于有冲突已经无法继续线性的添加到 master 分支上了。

                                          master
                                            |
--A---B------------C--------D-----E----F----G
      |            BJ a                     |
      |____a___b___e                        |
      |                                     |
      |___m___n__p___q______________________↓
                     b                      SH          

接下来 github 页面上已无法继续操作,需要在命令行中进行操作。命令行操作时,当前状态时 BJ 已通过 rebase 方式合并,接着合并 SH 分支。
在本地仓库对 SH 分支基于远端的 master 分支(已合并 BJ 分支)进行 rebase 操作。

git rebase origin/master
//执行后,git 会提示有冲突
//需要手动修改冲突文件
//然后 addcommit 继续 rebase
git rebase --continue
//上述处理的过程将会出现 4// 因为 SH 分支上有 m n p q 四个 commit 需要注意 rebase
git rebase --continue
//最后一个 rebase 执行完,git 不会报错
git push -f  origin SH

此时分支如图示,SH 分支有较大变化:

                                  master
                                    |
--A---B------------C------D---E--F--G--H--I--J--K
      |            BJ a                         |
      |____a___b___e                            |
      |                                        SH
      |___m___n__p___q
                     b                                    

接着将 SH rebase 进 master -- 这一步可以在 github 上操作。注意最后产生的结果是 master 又产生了4个新的分支,SH 分支因为 rebase变基后和最开始所在的 mnpq 分支已完全“脱离”。

                                                        master
                                                          |
--A---B------------C------D---E--F--G-------------L--M-M--O
      |            BJ a             |            
      |____a___b___e                |            
      |                             |--H--I--J--K          
      |___m___n__p___q                          SH
                     b                                    

git rerere

使用 rebase 时,如果有多个 commit,逐一处理冲突比较繁琐,这时可以使用 rerere ,该命令作用时:

Reuse recorded resolution of conflicted merges.

通过配置使其生效: git config --global rerere.enabled true,以后使用 rebase 时不需要对每个 commit 都手动修改。鉴于实际项目中几乎不会使用,这里不展开,可以查看git rerere 文档

54 集成服务

在 github Marketplace 中寻找需要安装的app。

后面两节一个是如何自动打包,一个是书写说明文档(wiki)。

57-62 Gitlab 实践