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的本地分支会跟踪到上游的工单分支。
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。
ref | description |
---|---|
refs/for/new | 为默认分支新建工单 |
refs/for/default | 为默认分支新建工单 |
refs/for/{branch} | 为指定分支新建工单 |
ref | description |
---|---|
refs/for/{id} | 添加新的补丁集到现存工单 |
ref | description |
---|---|
refs/heads/ticket/{id} | 快进式提交到现存补丁集 |
魔法式ref | 描述 |
---|---|
refs/for/{id} | 用于重写补丁集 |
在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}
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