Author: haoransun
Wechat: SHR—97
图片来源：极客时间，需个人购买教程。

1 创建团队项目

先在settings中创建组织类型的托管。然后在组织中创建团队的仓库。

点击 Create后出现当前画面

给予不同的人不同的权限

创建Team

2 选择适合自己团队的工作流

3 挑选合适的分支集成策略

Insights >> Network 中可以查看版本树的演进。

集成策略：

有的团队希望最后的历史树像一条线一样，应选择 *Allow rebase merging 或者 squash *

Beijing为例

Merge：特性分支合并到base分支上

Squash: 特性分支不动，base分支自动添加特性分支的所有变更为1个（如特性分支上有5个commit，base分支会5合1）

Rebase: 不改变特性分支，base分支会自动添加特性分支的所有变更，且不会合成一个

4 启用issue跟踪需求和任务

选用 stars:>100000 的开源项目来查看

点击 Lables 以 标签的形式查看

如何启用issue呢？

建立 issue后会出现类似的文件

5 使用project管理issue

不同的看板类型 显示效果不一样，以bug为例：

可以对任务分发，项目进度把握进行观察

6 项目内部如何 code review

根据需求对匹配到的不同分支做限制。

下面做了限制，防止对远端代码造成破坏。

7 团队协作如何做多分支的集成

特性分支总是有先有后的合成到base分支上，看看GitHub上是如何做

Merge:

beijing merge 到 base后：

shanghai 也要 merge 到 base:

在线编辑解决冲突。

此时的代码树：

pull request 选择 merge 后查看代码树的变化：

为了演示，将分支回退到之前的版本，实际上禁止这样处理

此时 master 回退

Squash:

beijing squash 到 base后：

将 beijing 特性分支上做的3次变更 集成到 master分支上，且3合1
新生成1个commit,不会改动特性分支。

shanghai squash 到 base后：

选中后就会报错 不能自动的merge,需要手动处理冲突

手动解决冲突后：

冲突解决，但还没有接收时的代码树

点击 Squash按钮后：

查看当前代码树：

master 再次回退

回到初始的状态：

Rebase:

beijing rebase 到 base后：
不改变特性分支，将 beijing分支的变更如实更新到 master分支上，不做合成。

shanghai rebase 到 base后：
会发生冲突，解决冲突后但还没有接收squash：

此时 pull request 已经走到死胡同，不能再往下走了

此时 Github 已经无能为力，但团队还是坚持要用 rebase。
可以将 shanghai 回退到 s这个节点

1
2

git branch -av  //确保本地分支在 s节点
git push -f origin Shanghai

我们应该回到ShangHai分支，让 ShangHai分支执行变基的操作，基于远端的master分支进行变基。

繁琐处理：
在本地做这件事，需要将远端的 master 拉取到本地

1
2

git fetch origin
git branch -av

切换到需要变基的分支，即 ShangHai分支，基于远端的 Master分支进行变基。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

git rebase origin/master //自然会报冲突 readme文件出了冲突

vi readme //解决冲突即可
git add .
git rebase --continue // 如果再次报冲突，继续处理

vi readme
git add .
git rebase --continue // 如果再次报冲突，继续处理

vi readme
git add .
git rebase --continue // 如果再次报冲突，继续处理，直到没有冲突

git status // 工作区是干净的即可
gitk --all // 查看分支树

继续推送即可

1
2
3
4
5
6
7

git push origin Shanghai // 会报 非 fast-forwards

同分支的本地往远端推送，必须是 fast-forwards才行

除非加上 -f

git push  -f origin Shanghai

此时，代码树发生了变化

再次查看 pull request发现可以 Rebase
即 远端的 master分支 与 远端的 ShangHai分支处理 Fast-Forward状态，不会再有冲突

有两个头像，一个是源文件的作者，一个是该文件的提交者。

特殊处理：

Git官网：找到 Documentation —>> Pro Git book 选择 简体中文
https://git-scm.com/

因为经过繁琐处理已经没有冲突，需要将ShangHai版本恢复到 远端 s节点继续演示

Master 分支也需要回退

开启 rerere

1
2
3
4
5
6

git config --global rerere.enabled true
git checkout ShangHai
git merge master //  只有看到Recorded resolution for ... 才算开始记录解决冲突的办法     当前报冲突，解决冲突
vim readme
git add .
git commit -am "temp"

因为只是为了记录解决冲突的方法，temp 这个 commit并不需要，所以需要回退

现在 ShangHai 等待着与 远端的 Master 做 rebase，并且使用 rerere

基于 master(7425314) 做 rebase

虽然报了冲突，但进去 readme看后发现 冲突内容被自动解决了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

git rebase  --continue
vi readme //冲突也没有 根据提示 添加 readme
git status

git add readme
git rebase  --continue
git status

git add readme
git rebase  --continue
git status

git add .
git rebase  --continue
git status  //一直到不再报冲突为止

git log -n5  // 查看commit是否如实更新上去

8 如何保证集成质量

通过 settings 中的 各种保险设置进行控制

也可在 市场中搜索各种 插件 APP 进行集成管控自己的代码。

9 产品如何发布到GitHub上

Release

如果是以 travis为例，需要在 .travis.yml文件中编写deploy的各种配置

api_key 不能暴露， 通过变量方式获取

name 是yml文件中的变量名称

value 在如下图中：在个人 setting 的 token中

pull request merge到主分支

经过 travis ci 各种审查后，点击 release即可看到

即通过 travis ci 通过 配置 travis.yml文件 将 java 工程部署到GitHub的 release中，期间要配置Token。

10 如何给项目添加详细的指导文档 (Wiki)

GitHub提供了 Wiki 功能

挑选别的开源项目中 wiki写的比较好的 下载下来，推送到自己的项目中才能进行各种 edit。

此时远端的 wiki 中 会出现别人的 wiki