Gitblit中採用Ticket模式進行共同作業開發

Git目前的程式碼分支管理模型中，比較主要的有Git-Flow、Github Pull Request。大家日常或多或少都在用著。

在不想安裝Gitlab這種重量級的環境的情況下，如果是利用git一步步搭建團隊的GIT服務的話，比較麻煩，而且維護更麻煩。Gitblit是一款比較簡單的跨平台Git自託管伺服器軟體，支援多種授權機制整合。

Gitblit自己也定義了一種基於Ticket的程式碼分支開發模型。

建立標準式工單

標準式工單(Standard ticket)是通過Gitblit Web 介面建立的。這種工單可以包含 Bug, Enhancement, task, 與 Question等型別。

建立提議式工單

提議式工單(Proposal ticket)是在推播一次單步提交(single commit )的程式碼時建立的，通過推播到指定魔法ref目標來實現。在Web 介面中無法建立這種工單。

為什麼會有這種單步提交的限制呢？

因為要從你這次提交的訊息中提取工單的標題與描述。工單建立之後，你可以隨意的提交程式碼到該工單對應的魔法分支。

什麼情況下建立提議式工單？

首先懶得開啟Web UI來建立工單啊。這種工單提供了一種很便捷的機制，允許你通過Git操作就可以對工單進行變更。

哪些人可以建立這種工單？

擁有clone倉庫許可權的任意授權使用者。

git clone https://server/r/repo.git
cd repo
git checkout -b mytopic
...add a single commit...
git push origin HEAD:refs/for/new
# read ticket id from server output
git branch -u origin/ticket/{id}

給已有的工單提交首個修補程式集

對於那種尚未提交修補程式集(patchset)的工單，可以到對應的工單分支ref來推播。

哪些人可以建立首次修補程式集？

擁有clone倉庫許可權的任意授權使用者

git clone https://server/r/repo.git
cd repo
git checkout -b ticket/{id}
...add one or more commits...
git push -u origin ticket/{id}

向現有工單的修補程式集安全的提交程式碼

哪些人可以向現有修補程式集新增提交？

• 工單建立者
• 修補程式集的初始建立者
• 在工單設定介面中被設定成負責人的人
• 擁有對所在的該倉庫讀寫許可權的任意使用者

git fetch && git checkout ticket/{id}
git pull --ff-only
...add one or more commits...
git push

對已有修補程式集的現存工單，想檢出命名化分支

預設檢出的工單分支是那種整數ID形式的，如果你想給本地工單分支命名的話，可以用下面的命令語法來實現。

git checkout -b my_fix --track origin/ticket/{id}

這樣命名為my_fix的本地分支會跟蹤到上游的工單分支。

重寫某個修補程式集(amend, rebase, squash)

哪些人可以重寫修補程式集？

Gitblit會檢測非快進式更新並建立新的修補程式集ref。這就保護了以前的修補程式集。

git fetch && git checkout ticket/{id}
git pull --ff-only
...amend, rebase, squash...
git push origin HEAD:refs/for/{id}

或者如果你有RW+的許可權，你可以直接用-f標識推播。

git push -f

對於重寫了的修補程式集更新你的工作副本

如果修補程式集被重寫，你不能在簡單的通過pull來更新。將你的分支更新到當前修補程式集的最簡單方式，是用-B標識reset。

git fetch && git checkout -B ticket/{id}

如果你有未提交的程式碼，你可以建立一個新的臨時分支，然後將你的變更以cherry-pick的胡合併到重寫後的修補程式集。

git branch oldticket ticket/{id}
git fetch && git checkout -B ticket/{id}
git cherry-pick <commitid1> <commitid2>
git branch -D oldticket

Git是非常靈活的，還有很多其他的策略來解決這種情況的問題。

Gitblit中工單Ref宣告格式規範(RefSpec)

Gitblit支援兩種原始的ref推播宣告格式：魔法式ref與修補程式集ref。

建立新的提議式工單

向現存工單新增提議式修補程式集(第一個修補程式集)

新增提交到現存修補程式集

重寫修補程式集 (amend, rebase, squash)

工單 RefSpec 小訣竅

在refspec推播語法中，支援直接設定一些工單欄位。

refs/for/master%topic=bug/42,r=james,m=1.4.1,cc=dave,cc=mark

範例

要給編號為12的工單建立新的修補程式集，並將james與mark兩人新增到watch列表，將主題設定為JIRA-123。註：這個格式的主題可以通過正則匹配的方式關聯到bugtraq設定。

git push origin HEAD:refs/for/12%cc=james,cc=mark,t=JIRA-123

新增一些提交(快進式)到#12號工單，對應里程碑為 1.4.1。

git push origin HEAD:refs/heads/ticket/12%m=1.4.1

合併修補程式集

Gitblit的Web介面提供了合併按鈕，會將修補程式集乾淨的合併到整合分支上。

複雜的合併場景，最好是用Git用戶端來合併。做這種操作有很多種方式，這裡提議一種安全的合併策略 - 將程式碼pull到一個新的分支、然後快進式合併到你的整合分支，假定你很樂意進行pull(merge)操作的話。

git pull origin master
git checkout -b ticket-{id} master
git pull origin ticket/{id}
git checkout master
git merge ticket-{id}
git push origin master
git branch -d ticket-{id}

通過push一個全新的修補程式集來關閉工單

Gitblit會在推播到普通分支時，茶軸修補程式集參照。如果找到參照或者在前一次合併說明中發現，該工單被以合併的型別被設定為已解決。並通過所有人。

如果你不需要建立用於評審的修補程式集，你可以直接推播包含 fixes #1或 cloes #1這樣字元的提交到整合分支。Gitblit會標識出該工單，建立以那次提交為說明的新修補程式集、並且將工單“解決”為已合併。

利用修補程式集重新開啟工單

Gitblit允許你通過合併修補程式集來重新開啟工單。既然Gitblit執行修補程式集重寫及版本化修補程式集，邏輯上是可行的。如果合併的提交沒有實際上解決掉該工單時，對於新特性需求或bug報告就無需建立另一個工單。

這讓你可以繼續該討論，並新建立希望解決該需求的修補程式集。

注意：你無法推播修補程式集到一個已經關閉的工單，Gitblit會拒絕。必須線充Web介面重新開啟，才能做後續的操作。

評審

Gitblit 包含了一種非常簡單的修補程式集評分機制。Gitblit不是程式碼評審系統，但可以滿足一些簡單的需求。

• +2, 通過：修補程式集可以被合併
• +1, 看起來是好的：必須由其他人通過後才能合併
• -1, 需要改進：請不要合併
• -2, 被否決：修補程式集不能被合併

擁有讀寫許可權的使用者可以給+/-2的分數，其他使用者只允許+/-1分。如果該倉庫被設定為“require approval”，那麼+2分就有更重要的意義。合併按鈕僅會在至少有一個+2且沒有-2的分數時出現。如果出現-2的打分，在Web介面上合併操作會被遮蔽。有讀寫許可權的使用者仍然可以手動合併並推播修補程式集到整合分支；Gitblit不會在push時強制否決修補程式集。

評審及更新的或重寫的修補程式集

如果該修補程式集被更新或重寫，以前的所有評審打分會被忽略掉；評審打分應用到修補程式集的指定版本 - 通過與否沒有什麼區別。

英文原文：http://gitblit.com/tickets_using.html

相關閱讀： 使用Gitblit 在Windows 上部署你的Git Server http://www.linuxidc.com/Linux/2013-07/87843.htm

在Ubuntu/Fedora/CentOS中安裝Gitblit  http://www.linuxidc.com/Linux/2015-03/115436.htm