Gitblit中采用Ticket模式进行协作开发

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 oldticket

Git是非常灵活的，还有很多其他的策略来解决这种情况的问题。

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时强制否决补丁集。

评审及更新的或重写的补丁集

如果该补丁集被更新或重写，以前的所有评审打分会被忽略掉；评审打分应用到补丁集的指定版本 - 通过与否没有什么区别。

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