47 | 创建团队的项目

在创建仓库时，Owner选择组织即可。

• 可以添加Team，赋予权限。

48 | 怎样选择适合自己团队的工作流？

需考虑因素：团队人员的组成、研发设计能力、输出产品的特征、项目难易程度。

1）主干开发方式（谷歌、Meta）

• 特点：变更直接集成到主干，快速迭代。
• 适用于：
  • 团队系统设计和开发能力强，有一套有效的特性切换实施机制，类似于功能开关能力；
  • 团队成员能力强，开发简单独立、升级成本低的组件，即组件开发。

2）Git Flow

• 特点：流程复杂，相对繁琐。
• 适用于：团队不具备主干开发能力，有预定的发布周期，对产品质量要求高，需执行严格的发布流程。

3）Github Flow

• 特点：master作为主线，相对Git Flow更严格。
• 适用于：团队不具备主干开发能力，需随时集成随时发布。

4）Gitlab Flow（+ 生产分支）

• 特点：master分支 + 生产分支，发布需要先部署到生产分支。
• 适用于：团队不具备主干开发能力，无法控制准确的发布时间。

5）Gitlab Flow（+ 环境分支）

• 特点：master分支 + 环境分支 + 生产分支，发布需要先部署到环境分支测试，测试通过再部署到生产分支。
• 适用于：团队不具备主干开发能力，需逐个通过各个测试环境的验证才能发布。

6）Gitlab Flow（+ 发布分支）

• 特点：master分支 + 多个发布分支，可维护不同版本。
• 适用于：团队不具备主干开发能力，需对外发布和维护不同版本。

小结：每种工作流都有自己的特点，但又有一些相似点，团队使用适合自己的即可。

49 | 如何挑选合适的分支集成策略？

版本树演进：Insights——Network

eg.

设置分支合并策略：Settings——Options——Merge Button，共3种。

1）非线性：用merge的方式合并（ git merge ，⚠️不是 git merge --squash ）

eg.

2）线性：将要合并的所有commits整合成一个commit，添加到目标分支上（ git rebase ，⚠️不是 git merge --squash ）

eg.

3）线性：将要合并的所有commits，添加到目标分支上（ git rebase ）

eg.

❗️：

• 当Github上有Pull Request后，管理者可以选择上面三种方式中的任意一种来合并（Github执行）。
• 后两种方式没有让分支相遇。

50 | 启用issue跟踪需求和任务

Issues

• 特点：状态分为open和close，通过Labels分类，通过Milestone标识大的版本变化。
• 可设置模板：Feature、Bug、自定义，可参考优秀的第三方库 。
• 作用：促进团队交流，记录交流细节。

PS：国内优秀库：vuejs/vue——Issues

51 | 如何用project管理issue？

Projects

• 创建看板功能，方便管理。
• 可设置模板，针对Issue、PR、CR等等。

52 | 项目内部怎么实施code review？

Settings——Branches——Add rule（Branch protection rules）

• 指定应用规则的分支pattern
• 勾选需要的规则，如code review

53 | 团队协作时如何做多分支的集成？

（合并结果参考第49节，本节探讨解决冲突方式）

场景：1）Beijing->master；2）Shanghai->master。⚠️：2）会产生冲突

• Merge

处理Shanghai->master的冲突：

Github会将先master合到Shanghai中解决冲突，形成新的commit后，再合入master

• Squash

处理Shanghai->master的冲突：

Github会将先master合到Shanghai中解决冲突，形成新的commit后，再进行squash合并操作

• Rebase

处理Shanghai->master的冲突：Github无法合并，会卡在解决冲突后。

手动方式：回退到如下状态；

在本地让Shanghai基于远端的master变基，解决冲突（4次，Shanghai的4次commit；更好的方式： git rerere ，官方文档）

将本地Shanghai分支强制推送到远端（因为已经不是fast-forwards）

最后再进行rebase合并操作：

相当于克隆了7个commits～

❗️看起来多此一举，但从另一个角度来看，其明确区分了Author和Committer的责任。

54 | 怎样保证集成的质量？

• 配置服务
  • 在Marketplace里找，如Travis CI、codecov等等，在项目的Setting--Integrations里可以配置。
  • 除此之外，可以在个人的Setting-- Developer settings--OAuth Apps配置第三方服务，或在GitHub Apps添加自己的或开源的服务。
• 配置分支保护规则
  • 去Settings--Branches--Branch protection rules设置，参考第52节。

55 | 怎样把产品包发布到GitHub上？

Release功能：将代码打包成二进制的压缩文件，方便测试、安装。

• 配置CI脚本（如.travis.yml）的before deploy和deploy部分；
• 配置token等。

56 | 怎么给项目增加详细的指导文档？

Wiki功能。

可参考优秀的wiki库，拉到本地，再推送到仓库对应的Wiki地址（项目名后面添加了.wiki），这样就可以编写自己的说明文档了。

• 可能需要去项目的Settings——Options里开启Wikis。

这是非常实用的一章，主要针对Github，下一章我们再一起看看Gitlab吧～