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

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

比如，像前面介紹過的，給禪道項目管理系統做了一個兼容redmine rest格式的用戶接口后，http://m.survivalescaperooms.com/x3d/p/4539246.html，就可以輕松的與gitblit整合了。

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.gitcd repogit checkout -b mytopic...add a single commit...git push origin HEAD:refs/for/new# read ticket id from server outputgit branch -u origin/ticket/{id}

給已有的工單提交首個補丁集

對于那種尚未提交補丁集(patchset)的工單，可以到對應的工單分支ref來推送。

哪些人可以創建首次補丁集？

擁有clone倉庫權限的任意授權用戶

git clone https://server/r/repo.gitcd repogit 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 mastergit checkout -b ticket-{id} mastergit pull origin ticket/{id}git checkout mastergit merge ticket-{id}git push origin mastergit 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