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