GitBlit使用说明书-Toy模板网

这篇具有很好参考价值的文章主要介绍了GitBlit使用说明书。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

GitBlit使用说明书

1. 概述

1.1 关于版本控制

1.2 Git是什么

1.3 GitHub Flow

1.4 目的

2. Scrum如何使用Git

2.1 Scrum使用githup flow

2.2 分布式工作流的选择

2.2.1 集中式工作流

2.2.2 集成管理者工作流

2.2.3 主管与副主管工作流

2.3 GitBlit协作方式

2.4 GitBlit中的Tickets功能

3. Scrum结合GitBlit使用流程

3.1 初始化项目

3.2 创建工单完成补丁集

3.3 解决冲突提交补丁集

3.4 合并补丁集

3.5 完成开发任务合并到master分支

4. GitBlit管理文本文件

4.1 使用GitBlit管理文本文件

5. 其他

5.1 新安装GitBlit中启用工单功能

概述
1. 关于版本控制

什么是“版本控制”？我为什么要关心它呢？版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。使用Git你可以对任何类型的文件进行版本控制。

如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能），采用版本控制系统（VCS）是个明智的选择。有了它你就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。

1. Git是什么

Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方式。从概念上来说，其它大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce、Bazaar 等等）将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异（它们通常称作基于差异（delta-based）的版本控制）。

参考资料: Git - Book

1. GitHub Flow

GitHub flow是一个轻量级的，基于分支的工作流，它支持定期进行部署的团队和项目。

参考资料: GitHub flow - GitHub Docs

http://scottchacon.com/2011/08/31/github-flow.html

1. 目的

团队开发中，遵循一个合理、清晰的 Git 使用流程，是非常重要的。否则，各种不清晰的分支结构，后续产品迭代或维护都会让人很头疼，再如果每个程序员都提交一堆杂乱无章的commit，后续的快速查找定位问题只能通过阅读代码，也是很低效的，特此制定此规范。

Scrum如何使用Git

Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

Scrum流程如下图：

gitblit,git,github,java

参考资料: https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html

1. Scrum使用githup flow

基于Scrum我们可以选择使用githup flow工作流来进行版本控制。

gitblit,git,github,java

1. 分布式工作流的选择

基于我公司现有开发规模及Scrum团队的特点,我们可以选使用集成管理者工作流方式进行Git 流程管理.

1. 1. 集中式工作流

集中式系统中通常使用的是单点协作模型——集中式工作流。一个中心集线器，或者说仓库，可以接受代码，所有人将自己的工作与之同步。若干个开发者则作为节点，即中心仓库的消费者与中心仓库同步。

1. 1. 集成管理者工作流

Git 允许多个远程仓库存在，使得这样一种工作流成为可能：每个开发者拥有自己仓库的写权限和其他所有人仓库的读权限。这种情形下通常会有个代表“官方”项目的权威的仓库。要为这个项目做贡献，你需要从该项目克隆出一个自己的公开仓库，然后将自己的修改推送上去。接着你可以请求官方仓库的维护者拉取更新合并到主项目。维护者可以将你的仓库作为远程仓库添加进来，在本地测试你的变更，将其合并入他们的分支并推送回官方仓库。这一流程的工作方式如下所示（见集成管理者工作流。）：

项目维护者推送到主仓库。
贡献者克隆此仓库，做出修改。
贡献者将数据推送到自己的公开仓库。
贡献者给维护者发送邮件，请求拉取自己的更新。
维护者在自己本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。
维护者将合并后的修改推送到主仓库。

gitblit,git,github,java

这是 GitHub 和 GitLab 等集线器式（hub-based）工具最常用的工作流程。人们可以容易地将某个项目派生成为自己的公开仓库，向这个仓库推送自己的修改，并为每个人所见。这么做最主要的优点之一是你可以持续地工作，而主仓库的维护者可以随时拉取你的修改。贡献者不必等待维护者处理完提交的更新——每一方都可以按照自己的节奏工作。

1. 1. 主管与副主管工作流

这其实是多仓库工作流程的变种。一般拥有数百位协作开发者的超大型项目才会用到这样的工作方式，例如著名的 Linux 内核项目。被称为副主管（lieutenant）的各个集成管理者分别负责集成项目中的特定部分。所有这些副主管头上还有一位称为主管（dictator）的总集成管理者负责统筹。主管维护的仓库作为参考仓库，为所有协作者提供他们需要拉取的项目代码。

1. GitBlit协作方式

Gitblit是一个开放源代码的纯Java堆栈，用于管理，查看和服务Git存储库。

它主要是为希望托管集中存储库的小型工作组设计的工具。

Gitblit融合了GitHub，BitBucket和Gerrit的元素，以基于主存储库中的分支提供简化的协作工作流。

基于历史原因, 我公司现使用GitBlit作为版本控制工具, 由于GitBlit与GitHub等其他Git版本控制有稍许区别,因此我们将会结合实际情况制定我司具体使用Git的流程

1. GitBlit中的Tickets功能

Gitblit的Tickets功能类似于GitHub / BitBucket Issues + Pull Requests。Gitblit并没有在问题和请求请求之间进行严格区分。在Gitblit中，所有票证可能都附加了提交，因此无需创建单独的新容器即可共享和讨论这些提交。此外，无需为同一代码的不同版本创建多个票证-这是其他系统中的常见做法。

参考资料: http://gitblit.github.io/gitblit/tickets_overview.html

Scrum结合GitBlit使用流程
1. 初始化项目

由该项目研发负责人负责在Git上创建项目仓库,并初始化项目,添加团队成员,创建开发分支,设置项目版本号等操作.除负责人外,其他人员均只有读权限,没有写权限.(后期根据实际情况可进行调整)

在GitBlit上创建项目

gitblit,git,github,java

添加团队成员

gitblit,git,github,java

使用git命令clone该版本库

git clone ssh://admin@localhost:29418/smart_lock.git

gitblit,git,github,java

在clone下来的文件夹内创建项目
git add . 暂存项目全部文件
git commit -m “init project” 提交项目到本地仓库

git push 推送到远程分支

gitblit,git,github,java

git tag -a v0.0.1 -m "my version 0.0.1" 设置版本标签
git push origin --tags 标签推送到远程仓库

gitblit,git,github,java

git checkout -b develop 检出开发分支

git push -u origin develop 推送到远程develop分支并追踪该分支

gitblit,git,github,java

1. 创建工单完成补丁集

项目研发团队成员clone项目,切换到开发分支创建工单,并提交第一个补丁,创建工单分支.在工单分支开发任务或解决bug.本地提交Git.根据实际情况适时的拉取dev远程分支合并到工单分支, 以便及时发现冲突并解决.

clone 项目

git clone ssh://myh@localhost:29418/smart_lock.git

在GitBlit UI 界面创建工单(暂不推荐)

gitblit,git,github,java

检出开发分支

git checkout --track origin/develop

创建工单分支

在创建工单分支之前你必须有一个提交,而且只能有一个提交.编写一些信息并提交.

git commit -a -m "听说这里的信息不能少于十个字,并且不能大于一百个字"

gitblit,git,github,java

lgit push origin HEAD:refs/for/new 创建工单并创建该工单的分支

gitblit,git,github,java

git checkout -b ticket/2

gitblit,git,github,java

git fetch

gitblit,git,github,java

git branch -u origin/ticket/2

gitblit,git,github,java

git commit -a -m "第二次提交补丁,其实也没解决什么问题"

gitblit,git,github,java

注: GitBlit 工单功能不仅仅是这些,在不熟悉的情况下请参照命令行创建工单.想使用更多功能, 请参考: https://zhuanlan.zhihu.com/p/494988089

1. 解决冲突提交补丁集

待该工单完成之后,必须拉取远程dev分支合并到本地工单分支,解决冲突后推送到远程分支.并提醒改项目研发负责人将工单分支合并到开发分支,以便测试人员能够及时的进行测试.

1. 合并补丁集

项目负责人接到对应工单完成的通知之后,负责拉取对应工单分支,审查代码,如代码有明显问题,不予合并,通知到对应开发人员,说明问题原因,重新修改,如无问题,将该分支合并到开发分支推送到远程仓库,并通知测试人员进行测试.

1. 完成开发任务合并到master分支

当前冲刺所有任务及bug全部解决完成并经过测试演示等环节后,由项目负责人将当前开发分支的全部修改合并到master分支.

GitBlit管理文本文件
1. 使用GitBlit管理文本文件

Git是一个版本控制系统, 除了管理研发出来的源代码外,它也可以管理相关的文本文件. 要求项目相关的所有资料全部上传到项目根目录下的docs文件下, 可以在该文件夹下创建子文件夹. 上传资料包括单不限于项目调研资料, 项目需求文档, 项目原型, UI设计图, 概要设计文档, 详细设计文档等.

其他
1. 新安装GitBlit中启用工单功能

GitBlit默认没有开启工单功能, 需要在配置文件”GitBlit_Home\data\defaults.properties”中加入对应的配置: tickets.service = com.gitblit.tickets.BranchTicketService文章来源地址https://www.toymoban.com/news/detail-752799.html

1. 一般分支命名规范
master: 主分支，主要用来版本发布。
develop：日常开发分支，该分支正常保存了开发的最新代码。
feature：具体的功能开发分支，只与 develop 分支交互。
release：release 分支可以认为是 master 分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release 分支，测试没有问题并且到了发布日期就合并到 master 分支，进行发布。
hotfix：线上 bug 修复分支。

到了这里，关于GitBlit使用说明书的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！