Pull Request
向開源項目提出你的合併
- Fork
fork 你想 PR 的項目到自己的倉庫。
- clone
把 fork 的項目 clone 到本地。
- branch
創建一個 work 特徵的特徵分支，並切換到該分支下。
- 添加代碼提交修改
提交到對應的特徵分支下，沒有的話自己在 GitHub 新建一個遠程分支
- 發送你的 pull request
根據要合併項目的 issues 要求規範填寫你的合併緣由，等待管理員的處理
開發中的 Pull Request
對可能實現的功能或更改進行討論，可以使用 TaskList ，這樣可以清晰的瞭解到哪些功能沒有實現，哪些功能已經實現增加審查者的效率，也可以做爲備忘錄使用。
接收 Pull Request
- 代碼檢查
將接收的內容放在本地，使用集成測試進行檢查，檢驗代碼是否能運行和安全，是否符合規範和要求。
在本地檢查需要合併的內容
- 將接收的本地倉庫更新到最新
- 獲取附送方的遠程倉庫
- 創建用於檢查的分支
- 合併
將通過檢查的檢查分支代碼與提交者的特徵分支進行合併
- 刪除分支
刪除用於檢查的分支
確認安全的合併
如果以上代碼檢查沒有問題就可以在 Pull Request 頁面點擊 Merge pull request，進行合併。
這個合併過程是一個自動的過程，如果代碼比較少，可以直接在 GitHub 網站的網站對比直接進行合併。
GitHub Flow 的開發流程
開發流程
- 令 master 分支處於隨時可部署的狀態
- 進行新的作業時要從 master 分支創建新的分支，新分支名稱要具有描述性
- 在創建的本地分支進行提交
- 在 GitHub 端創建同名分支，定時 push
- 需要幫助或者反饋時創建 Pull Request ，以 Pull Request 進行交流
- 讓其它開發者進行審覈，確認作業完成後與 master 分支合併
- 與 master 分支合併後立即部署
具體介紹
- 實時部署，沒有發佈的概念
- 進行新的作業時要從 master 分支新建新的分支
- 在新創建分支中進行提交
提交粒度小，一旦完成小的任務，就提交
- 定期 push
備份代碼。定時交流
- 使用 Pull Request
不是在最後 master 合併時才 PR，而是寫完一部分功能後就 PR ,這樣可以一邊編碼，一邊聽取他人的修改意見
- 務必讓其他開發者進行審查
審查時找沒有參與作業的，而且代碼應該通過自己的測試
- 合併後立即部署
確認合併後的代碼是否存在問題
實踐GitHub Flow 的前提
部署作業完全自動化
- 使用部署工具
- 通過 Web 界面進行部署的工具
- 實施部署時的鎖
重視測試
- 讓測試自動化
- 編寫測試代碼，通過全部測試
- 維護測試代碼
Git Flow 的開發流程
以發佈爲中心的開發模式
標準工作流
- 從開發分支創建工作分支，進行功能的實現或修正
- 工作分支結束後與開發分支進行合併
- 重複 ① ② 直至功能可以發佈
- 創建用於發佈的分支，處理髮布的各項工作
- 發佈工作完成後與 master 分支合併，打上版本標籤進行發佈
- 如果發佈的軟件出現 BUG ，以打了標籤的版本爲基礎進行修正
導入 Git Flow 的準備
- 安裝 git-flow
- 倉庫初始化
- 創建倉庫
- 進行 git-flow 的初始化
- 在遠程倉庫也創建 develop 分支
Git Flow 工作流
master 分支與 develop 分支的區別
master 分支始終保持可發佈的穩定狀態，發佈時必須包含版本標籤。這個分支不允許開發者直接修改和提交。develop 分支是開發過程中的代碼中心，這個分支和 master 分支一樣不允許開發者直接修改和提交。程序員需要自己新建 feature 分支，在 feature 分支中開發和修正。也就是說，develop 分支維持着開發過程中的最新源代碼。
在 feature 分支中的工作
- 從 develop 分支創建 feature 分支
- 在 feature 分支中實現目標功能
- 通過 GitHub 向 develop 分支發送 Pull Request
- 接收其他開發者審覈後，將Pull Request 合併到 develop 分支
完成的 feature 適當時間進行刪除
通過代碼審查實現代碼質量的提升
- 由其他開發者進行代碼審查，反饋在 Pull Request 中
- 修正代碼反饋的內容
- 將修改後特徵分支推送到遠端（自動添加到之前的 Pull Request）
- 重複前三步
- 確認 Pull Request 沒有問題，合併到 develop 分支
反饋的幾個要點：
- 沒有測試or未通過測試
- 違反編碼原則
- 代碼品質過低（命名不明確， 方法冗長）
- 還有重構的餘地
- 有重複的部分
在 release 分支的工作
- 創建分支
以最新的 develop 分支創建一個發佈分支
- 分支內的工作
只處理與發佈前有關的提交，如：版本編號變更、bug 的修正。該分支不能包含功能的添加、變更等內容
- 進行發佈與合併
合併至 master 將項目發佈
- 查看版本標籤
$ git tag 在 hotfix 分支中的工作
- 創建新的補丁分支
- 進行版本修復
- Pull Request
- 創建標籤併發布
- 最後將它合併到開發分支
版本號的分配規則
格式： x.y.z
- x 在重大內容更新或不向下兼容時加 1，此時 y、z 歸 0
- y 在添加或刪除新功能加 1，此時 z 歸 0
- z 只有在內部修改時加 1
舉個例子：
- 1.0.0：最初發布的版本
- 1.0.1：修復了輕微的 BUG
- 1.0.2：修復了漏洞
- 1.1.0：添加了新功能
- 2.0.0：更新整個 UI 並添加新功能
注意事項
在合併後更新本地 develop 分支
將 develop 分支設爲默認分支，省去手動切換分支的麻煩
引用
[1] GitHub入門與實踐