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。
创建新的提议式工单
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
相关阅读: 使用Gitblit 在Windows 上部署你的Git Server http://www.linuxidc.com/Linux/2013-07/87843.htm
在Ubuntu/Fedora/CentOS中安装Gitblit http://www.linuxidc.com/Linux/2015-03/115436.htm
如何在Linux下使用Gitblit工具创建Git仓库服务 http://www.linuxidc.com/Linux/2015-06/118299.htm
Gitblit 的详细介绍:请点这里
Gitblit 的下载地址:请点这里
本文永久更新链接地址:http://www.linuxidc.com/Linux/2015-12/126526.htm