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 吧～