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

IngeniousIT 2015-12-20

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的本地分支会跟踪到上游的工单分支。

重写某个补丁集(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。

创建新的提议式工单

refdescription
refs/for/new为默认分支新建工单
refs/for/default为默认分支新建工单
refs/for/{branch}为指定分支新建工单

向现存工单添加提议式补丁集(第一个补丁集)

refdescription
refs/for/{id}添加新的补丁集到现存工单

添加提交到现存补丁集

refdescription
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

Gitblit 的详细介绍:请点这里
Gitblit 的下载地址:请点这里

相关推荐