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时强制否决补丁集。
评审及更新的或重写的补丁集如果该补丁集被更新或重写，以前的所有评审打分会被忽略掉；评审打分应用到补丁集的指定版本 - 通过与否没有什么区别。
相关阅读： 使用Gitblit 在Windows 上部署你的Git Server