引言
整理了下之前极客时间上《玩转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 会提示有冲突
//需要手动修改冲突文件
//然后 add， commit 继续 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 实践
略
Comments