以前使用GitHub一般就作為版本管理+bug管理，都是個人使用，這次公司全部統一使用GitHub企業版進行開發管理，在使用過程中感覺還蠻不錯的。可以實現類似看板的功能，還很便於交流。

專案管理

在記錄GitHub應用前，先來看看專案管理的一些情況。整個專案偏向于敏捷的管理方式，儘量簡化，當然也不是完全一樣。專案前後端完全獨立，採用REST介面。

開發環境：準備了專門的開發伺服器、構建伺服器，用於構建以及部署服務，還有一個獨立的整合測試伺服器，用於自動化定期部署服務及整合測試。開發工具使用IDEA，並且使用編碼約定，包括統一的Code Style、import順序配置、static import配置、CheckStyle外掛配置、換行符設定，以保證每個開發人員格式化都是完全一致的。

review：所有PR（PullRequest）必須至少2人（子團隊4個成員）進行review，實際執行過程中，基本都是所有成員全部review後才進行merge的，只有部分大範圍重新命名或者很小的簡單修改除外，當然，這個是約定，這個沒有技術手段限制，缺點很明顯，review需要佔用不少時間，優點也很明顯，一個是程式碼質量更高，另一個是都比較瞭解所有程式碼，可以互相替代。在執行過程中發現，花費一些代價review是值得的。但也不一定這麼死板，總的來說，前期最好所有成員都進行review，可以起到整體風格統一的作用，而且很高效，也可以讓大家都瞭解整個專案的大體情況。

持續整合（CI）：這個是使用Jenkins完成的，每日定時構建並部署到開發伺服器。專案的特點是前後端分離，及時的部署到開發伺服器便於前端開發測試。除了每日構建，Jenkins利用Git和GitHub外掛與GitHub整合，在每一次PR有提交的情況下也會觸發構建。Jenkins構建使用的是maven，除了編譯、單元測試以外，還會進行Findbug、CheckStyle、單元測試覆蓋（JaCoCo）等檢測，保證PR中沒有Findbug的最高級別警告以及沒有CheckStyle的任何警告。

Profile類別：local、test、dev、alpha、stage、real，local是指開發人員本地，test是指單元測試，dev是指開發環境。

介面定義：沒有采用專門的文件，使用Swagger在程式碼中定義。先期在GitHub的wiki中專門有一篇文件，後來感覺重複維護容易遺漏，就沒有使用了，都以Swagger定義為準。

GitHub常用功能

git作為專案倉庫進行版本管理這個大家都只到，GitHub的Code不需要在介紹了。這裡只介紹與開發管理相關的功能，而且假設大家已經瞭解了基本的操作。

Issues：問題單，不要僅僅把它看作別人提單自己改進的功能，藉助自定義label，它可以包羅永珍，可以是功能點（new feature）、改進點（improvement）、研究技術（research）、分享資訊（share）、討論問題（discussion）等等，為什麼把這麼多東西都當作issue呢，因為一旦使用issue來管理，就可以利用GitHub功能很方便的跟蹤、通知、引用關聯等等。比如一個需要討論的問題，可能是在完成某個功能issue的時候產生的，就可以方便的refer哪個功能issue（#issue號）。

Pull Reqeust（PR）：合併申請，在分支上進行了一些修改，需要很併到其他分支，就需要建立一個PR，一般情況下的配置就是要求需要review後才能合併。在提交PR的時候，約定需要寫明關聯的issue，以及該PR涉及了哪些改動，以方便他人review。

Wiki：可以用來存放一些簡單文件，比如需求描述、開發約定、開發環境說明等等，總之，需要成員都知道而且需要隨時檢視的都可以放到這裡。

ZenHub介紹

這是一個Chrome的外掛（所以還是用Chrome好呀），ZenHub主頁上可以看到，它就是用於敏捷管理。安裝外掛後只需要填寫帳戶資訊即可。

外掛安裝後再開啟GitHub頁面，就會發現多了兩個功能：Boards和Burndown。Boards就是便於issue狀態管理的，類似看板，在不同的狀態列中的issue可以隨意拖動到其他狀態列，就可以變更issue狀態。具體一些操作就不詳細說明了。

board

Burndown（燃盡Report）就是一個資訊彙總。除此以外，還可以在Boards中看到有一欄叫做Epics，這個是多個issues的集合，在建立issue的時候在右側還可以看到多了pipeline和estimate的選擇，estimate就是評估的價值。

new-issue

下面主要介紹一下工作流程相關的常用功能。

Epics：在建立New Issue的時候，會多出一個Create an epic選項，可以建立epic，epic的含義就是一個稍大的工作，它包含多個子工作（issues），一開始工作的劃分可能並不能很細緻，因此建立epic比較合理。確定子工作後，可以把issue新增到epic中。

issue-to-epic

pipeline：工作線，其實含義就是處理的狀態，整個狀態串起來就是工作流程，pipeline可以自定義，一般使用預設的就可以了，預設包括以下幾個狀態：

New Issue：新建立的issue預設就是這個狀態。

Epics：這個不是狀態，就是指epic。

IceBox：凍結issue，暫時不去完成，可能是issue太複雜或者需求不確定等等。

Backlog：issue計劃執行，就是迭代會議的時候確定哪些工作需要完成，那麼相應issue就變更為backlog狀態。

In Progress：在進行中，一旦開發人員著手執行issue，就變更為in progress，當然，這裡就要注意了，在進行中的issue一定要有指定的開發人員（Assignees），這樣可以避免重複工作。

Review/QA：等待或正在進行review或者QA測試。

Close：關閉，確認完成後變更為關閉。

Done：已經完成，這個狀態比較特別，前期是PR合併後變更為該狀態，在迭代會的時候大致梳理，確認完成就變更為close，後來認為這樣很耗時間，也沒有起到什麼作用，就約定，如果是開發階段issue，完成後就變更為close狀態，如果是需要QA測試的，才用到Done狀態。

工作流程

以一個迭代來說明：

1. 建立一個milestone，命名需要有一個規範，便於識別。

2. 根據需求建立issue和epics，如果issue之間有關聯，就引用即可。

3. 根據進度要求及當前完成情況，將當前迭代計劃執行的issue的pipeline變更為backlog。

4. 根據情況自行領取或指定負責人員，開支進行時將issue的pipeline變更為in progress。

6. 不需要QA測試的issue一旦review透過，就自行將pipeline變更為close。如果需要QA測試，則等待測試，測試完成後，如果透過則變更為done，經開發確認後close，如果未透過，則變更為in progress繼續進行。

7. issue的處理有不同的方式

開發類issue：建立一個git分支，命名為#[issue號]_描述，push到遠端。然後在本地分支上進行修改，重要的commit comment中引用issue號，儘量合併commit，完成並push到遠端，提交PR（在此最好合並主分支）。

其他約定和建議

儘量多的利用GitHub，能在GitHub上進行的工作都用GitHub，這樣互相關聯，查詢跟蹤更加方便。

在各種comment中可以引用各種內容，比如#引用issue，@引用人員，還可以直接貼上url，比如可以貼上某一個comment的url（comment的時間是一個超連結，這個連結url就是comment的url）。下圖中兩個藍色框，第二個就是其他issue引用了這個issue，可以很方便的連結過去。第一個藍色框是在git提交時，在comment中引用issue，一旦引用，在issue中就可以看到相關的commit。詳細參考GitHub說明https://guides.github.com/features/mastering-markdown/。

refer-comment

wiki中如何新增附件？wiki中無法上傳檔案，但是issue的comment可以上傳，因此，可以現在comment處上傳檔案，上傳後可以得到檔案的url，複製這個url到wiki中，就可以引用到該檔案。可以注意到，其實各個元素都有固定的url（符合REST風格），都可以使用url進行引用。（但是附件支援的格式有限，有的時候只能改一個字尾名進行上傳，比如sql檔案，就可以改成txt檔案上傳）

強烈建議最終需要執行的issue足夠小。儘量小的issue將使得工作進度更可控，任務更明確，修改也更簡單，如果issue需要對應PR，PR需要review的變更會比較少，這樣review的程序也會加快很多。在專案中，採用的衡量方式是issue的完成不超過3天。或者PR的變更在10個檔案以內（當然不是必須的規定，而是指在一個範圍內其他成員會樂意review，如果過多修改，review會變得很困難很耗時，經常會出現拖延現象），因此，這也是issue劃分的一個重要依據，要儘可能的推動review，推動進度。

禪道可以的，應該可以滿足你的要求。國內開源的系統，也有收費的專業版企業版之類的。一般的開源版可以滿足大部分要求了。支援整合git，svn，最新版還加了測試框架（個人還沒用到）。支援專案和產品的管理。目前10人左右的團隊用著，挺好。