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的本地分支會跟蹤到上游的工單分支。
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推送聲明格式:魔法式ref與補丁集ref。
在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}
Gitblit會在推送到普通分支時,茶軸補丁集引用。如果找到引用或者在前一次合並說明中發現,該工單被以合並的類型被設置為已解決。並通過所有人。
如果你不需要創建用於評審的補丁集,你可以直接推送包含 fixes #1或 cloes #1這樣字符的提交到集成分支。Gitblit會標識出該工單,創建以那次提交為說明的新補丁集、並且將工單“解決”為已合並。
利用補丁集重新開啟工單
Gitblit允許你通過合並補丁集來重新開啟工單。既然Gitblit運行補丁集重寫及版本化補丁集,邏輯上是可行的。如果合並的提交沒有實際上解決掉該工單時,對於新特性需求或bug報告就無需創建另一個工單。
這讓你可以繼續該討論,並新創建希望解決該需求的補丁集。
注意:你無法推送補丁集到一個已經關閉的工單,Gitblit會拒絕。必須線充Web界面重新開啟,才能做後續的操作。
Gitblit 包含了一種非常簡單的補丁集評分機制。Gitblit不是代碼評審系統,但可以滿足一些簡單的需求。
擁有讀寫權限的用戶可以給+/-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
如何在Linux下使用Gitblit工具創建Git倉庫服務 http://www.linuxidc.com/Linux/2015-06/118299.htm
Gitblit 的詳細介紹:請點這裡
Gitblit 的下載地址:請點這裡