Git目前的代码分支管理模型中，比较主要的有Git-Flow、Github Pull Request。大家日常或多或少都在用着。
在不想安装Gitlab这种重量级的环境的情况下，如果是利用git一步步搭建团队的GIT服务的话，比较麻烦，而且维护更麻烦。Gitblit是一款比较简单的跨平台Git自托管服务器软件，支持多种授权机制整合。
比如，像前面介绍过的，给禅道项目管理系统做了一个兼容redmine rest格式的用户接口后，http://www.cnblogs.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.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 oldticketGit是非常灵活的，还有很多其他的策略来解决这种情况的问题。
Gitblit中工单Ref声明格式规范(RefSpec)
Gitblit支持两种原始的ref推送声明格式：魔法式ref与补丁集ref。
创建新的提议式工单
| ref | description |
|---|---|
| refs/for/new | 为默认分支新建工单 |
| refs/for/default | 为默认分支新建工单 |
| refs/for/{branch} | 为指定分支新建工单 |
向现存工单添加提议式补丁集(第一个补丁集)
| ref | description |
|---|---|
| refs/for/{id} | 添加新的补丁集到现存工单 |
添加提交到现存补丁集
| ref | description |
|---|---|
| refs/heads/ticket/{id} | 快进式提交到现存补丁集 |
重写补丁集 (amend, rebase, squash)
| 魔法式ref | 描述 |
|---|---|
| refs/for/{id} | 用于重写补丁集 |
工单 RefSpec 小诀窍
在refspec推送语法中，支持直接设置一些工单字段。
refs/for/master%topic=bug/42,r=james,m=1.4.1,cc=dave,cc=mark| 参数 | 描述 |
|---|---|
| t | 指定工单的主题 |
| r | 设置负责人 |
| m | 设置补丁集集成到的里程碑 |
| cc | 将指定的一个或多个帐号添加到watch列表 |
示例
要给编号为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时强制否决补丁集。
评审及更新的或重写的补丁集
如果该补丁集被更新或重写，以前的所有评审打分会被忽略掉；评审打分应用到补丁集的指定版本 - 通过与否没有什么区别。