使用git、git-flow与gitlab工作 - Axb的自我修养
使用git、git-flow与gitlab工作
十一月 2, 2013
在工作中使用git代替svn也有一段时间了，对于git的一些特性爱不释手的同时也一直遇到相同的问题：“这时候应该打什么命令？”。相对于svn或者vss的简单，git的学习成本还是有些高，如果要使用一个工具还要翻上300页的《Pro Git》，工具的使用成本甚至大于开发本身，这也是我写这篇文章的初衷。
Linux下可以直接用apt-get install git或者yum安装。
注：这篇教程里所有git操作在命令行下执行，windows下可以右键-git bash打开命令行。
如果有人告诉你某某项目的git地址：
git clone username@host:/path/to/repository
或者是你只想自己折腾一下,建立一个空白的版本库：
要提交代码到git仓库需要两个命令：
git commit -m “代码提交信息”
要撤销提交：
git reset HEAD
要从从版本库恢复文件：
git checkout —
在git文件夹中实际存在三个区域：
实际目录：实际修改的文件。
待提交区：暂存准备提交的内容，提交之后被清空。(也叫做index区）
已提交区：提交到本地git版本库的内容，有版本号。
对这三个区域的操作都可以在本地离线完成。
完整一些的状态图如下：
查看文件状态：
git status
文件总共四种状态：
与git repository一致
与git repository不一致，已缓存
与git repository不一致，未缓存
还未添加到git repository
从远程更新：
提交到远程：
远程git与本地git的关系大概是这样：
其中：remotes/origin是git用来管理远程版本库的的隐藏分支，一般不用理会。
分支是用来将特性开发绝缘开来的。在你创建仓库的时候，master 是“默认的”。在其他分支上进行开发，完成后再将它们合并到主分支上。
创建一个叫feature_x的分支，并切换过去：
git branch feature_x
git checkout feature_x
切换回主分支：
git checkout master
再把新建的分支删掉：
git branch -d feature_x
除非你将分支推送到远端仓库，不然该分支就是 不为他人所见的：
git push origin
如果要删除远端仓库里的某个分支：
git push origin :
要合并其他分支到你的当前分支（例如 master），执行：
两种情况下，git 都会尝试去自动合并改动。不幸的是，自动合并并非次次都能成功，并可能导致 冲突（conflicts）。 这时候就需要你修改这些文件来人肉合并这些 冲突（conflicts） 了。改完之后，你需要执行如下命令以将它们标记为合并成功：
在合并改动之前，也可以使用如下命令查看：
在软件发布时创建标签，是被推荐的。这是个旧有概念，在 SVN 中也有。可以执行如下命令以创建一个叫做 1.0.0 的标签：
git tag 1.0.0
在工作中，用一个分支来处理开发、测试、发布、线上hotfix等等流程是难以控制的：项目上线前你只想让其他人提交一个小修改，结果fetch下来的是另一个人为下次上线提交上来的几百个文件修改。
这里介绍利用git分支的特性避免这种情况的一种做法：
首先，git远程版本库有两个永久分支，master与develop。
develop分支包含开发过程中最新的提交变更。有人会称之为“集成分支”。该分支是自动化每日构建的代码源。
当develop分支上的源码到达一个稳定的状态时，就可以发布版本。所有develop上的变更都应该以某种方式合并回master分支，并且使用发布版本号打上标签。
每次有变化被合并到master分支时，这就是一次新的产品版本发布。
临时分支是开发或者发布过程中被创建、一段时间后再删掉的分支，同一时间内可能会有多个临时分支在并行工作。
作用：开发新的功能
分支来源：develop
分支结束时合并到：develop
特 性分支（有时也被称作topic分支）是用来为下一发布版本开发新特性。当开始开发一个特性的时候，该特性会成为哪个发布版本的一部分，往往还不知道。特 性分支的重点是，只要特性还在开发，该分支就会一直存在，不过它最终会被合并回develop分支（将该特性加入到发布版本中），或者被丢弃（如果试验的 结果令人失望）。
特性分支往往只存在于开发者的本地仓库中。
作用：准备发布新版本
可能的分支来源：develop
分支结束时合并到：develop和master
发布分支为准备新的产品版本发布做支持。它允许你在最后时刻检查所有的细节。此外，它还允许你修复小bug以及准备版本发布的元数据（例如版本号，构建日期等等）。在发布分支做这些事情之后，develop分支就会显得比较干净，也方便为下一大版本发布接受特性。
从 develop分支创建发布分支的时间通常是develop分支（差不多）能反映新版本所期望状态的时候。至少说，这是时候版本发布所计划的特性都已经合 并回了develop分支。而未来其它版本发布计划的特性则不应该合并，它们必须等到当前的版本分支创建好之后才能合并。
正是在发布分支创建的时候，对应的版本发布才获得一个版本号——不能更早。在该时刻之前，develop分支反映的是“下一版本”的相关变更，但不知道这“下一版本”到底会成为0.3还是1.0，直到发布分支被创建。版本号是在发布分支创建时，基于项目版本号规则确定的。
作用：修复发行版bug
分支来源：master
分支结束时合并到：develop和master
热 补丁分支和发布分支十分类似，它的目的也是发布一个新的产品版本，尽管是不在计划中的版本发布。当产品版本发现未预期的问题的时候，就需要理解着手处理， 这个时候就要用到热补丁分支。当产品版本的重大bug需要立即解决的时候，我们从对应版本的标签创建出一个热补丁分支。
使用热补丁分支的主要作用是（develop分支上的）团队成员可以继续工作，而另外的人可以在热补丁分支上进行快速的产品bug修复。
在了解如何review之前先明确几个观点：
1、master分支中的任何版本都认为是可以立即部署的
2、每一次master分支的变更都来自于其它分支向master的合并操作。
3、对master的修改需要review。
借助于gitlab的merge request机制，与上面说的工作流程，我们可以在release分支正式合并到master分支之前建立merge request，在其他人review完成这次合并之后再正式进行合并。
1、将需要合并到master的分支push到gitlab。
2、进入工程-merge request -create new merge request
3、选择源分支、目标分支，确定。
4、review负责人进入merge request，确认没有问题之后选择Auto Merge（或者手动在本地合并之后再push到gitlab），并关闭这个merge request，完成。
5、如果发现问题那么在有问题的行下注释，并提醒request的发起人及时修改。
git flow是git的辅助工具，实质上是一些分支-合并的脚本集合，使用git flow可以更轻松的完成对各种特性分支的操作。
apt-get install git-flow
将git库转换为git-flow库：
git flow init
实质上这一步只是为git flow中的几个特性分支命名。
开始一个新功能：
git flow feature start xxxx
提交这个功能到远程库：
git flow feature publish xxxx
完成功能，合并到develop：
git flow feature finish xxxx
记得删除远程仓库里的分支：
git push origin :xxxx
release,hotfix与之类似，唯一的一点区别：hotfix目前没有publish功能，所以提交远程仓库的这一步要改成：
git push origin hotfix/xxxx:hotfix/xxxx
git flow只是在本地执行分支/合并操作的脚本，不是一个流程管理工具。
几个常用命令：
A). –hard：重设（reset） index和working directory，自从以来在working directory中的任何改变都被丢弃，并把HEAD指向。
B). –soft：index和working directory中的内容不作任何改变，仅仅把HEAD指向。这个模式的效果是，执行完毕后，自 从以来的所有改变都会显示在git status的”Changes to be committed”中。
C). –mixed：仅reset index，但是不reset working directory。这个模式是默认模式，即当不显示告知git reset模式时，会使用mixed模式。
**git checkout **
-b 签出并创建分支
-t 签出并追踪远程分支
**git rebase **
合并/修改提交
git remote -av
显示所有远程仓库
git push -u
设置分支对应的远程仓库
《Pro Git》
本作品采用进行许可，转载请注明作者及原网址。当前位置: &>&&>& >
我理解的Git Flow
Git FLow是什么
Git Flow是构建在Git之上的一个组织软件开发活动的模型，也是软件开发过程中一种成功的分支管理策略。它的核心思想是利用成功的分支管理策略，管理软件的开发过程。
2010年5月，nvie 在他的“A successful Git branching model”一文中，介绍了这种模型，并将其命名为Git Flow。而且，他还为这种分支策略开发了一套Git扩展工具，我们可以在Git中，使用专属的分支管理命令操作分支。
因此，Git Flow 是一种软件开发模型，由一种分支管理策略，和一套与之配套的Git扩展工具组成。
下面这张图，形象的展示了Git Flow的全貌：
Git Flow中的分支
根据Git Flow的思想，开发人员需要合理的利用Git的分支功能，来管理软件的开发流程。因此，Git FLow模型定义了五种标准的分支，并且让它们各司其职，分别是：master分支，develop分支，feature分支，hotfix分支和release分支。
这五种分支又可分为两大类：主要分支和辅助分支。主要分支，包括master分支和develop分支。辅助分支，包括feature分支，hotfix分支和release分支。
实质上，Git Flow就是要求开发者使用这五种标准的分支管理软件开发流程。
主要分支只用于与软件测试、部署、发布相关的活动，不会涉及任何的软件开发活动。主要分支会一直存在，是所有其他分支的源头，也是它们最终的归宿。
master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。它是源头中的源头，归宿中的归宿。它只用于新版本的发布，不涉及一切与软件开发、测试、部署有关的操作。
develop分支fork自master分支，主要用于开发工作。开发新功能时，从develop分支拉出feature分支。新功能开发完成后，再把feature分支合并到develop分支。可见，develop分支是一个承上启下的分支。
辅助分支主要用于具体的软件开发工作，包括新功能的开发、Bug修复和发布前的准备工作。辅助分支不是一直存在的，当它们被合并到主要分支后，会被删除掉。
开发者不能直接在master分支和develop分支上做开发工作，这样可能会污染软件的版本库。Git Flow要求从develop分支上引出一条feature分支，专门做具体的开发工作。每个开发者都可以从develop分支上引出自己的feature分支，并且这个feature分支是开发者私有的，可以不必提交到版本库中。开发完成后，把所有的feature分支都合并到develop分支上，然后把feature分支删掉。如果新功能被砍掉了，也可以直接删掉feature分支。
当线上产品遇到了严重Bug，或者发现了紧急的缺陷，不得不立即修复时，就可以从master分支引出一条hotfix分支。问题解决后，再把hotfix分支合并到master分支和develop分支，最后删除掉这个hotfix分支。这样做的好处是使Bug修复与新功能开发完全分离开，保证开发工作不受到影响。
当新功能开发完，代码都合并到develop分支后，就可以为新版本发布做准备了。但是如果这时有新的开发任务到来，或者又有新的分支需要合并，而此时的develop分支又没有准备好合并到master分支时，那么就可以从develop分支引出一条release分支作为过渡。在release分支上，完成发布前的准备工作，然后合并到master分支和develop分支，最后删除release。release分支可以使develop分支解放出来，尽早的投入到下一版本的开发中。
Git FLow的使用方式
使用原生的Git命令
Git Flow本质上就是对git分支的利用，所以用原生的git分支命令就可以操作。
创建分支从当前分支上引出新的分支
git branch branch_name
git cheout branch_name
创建并切换分支
git cheout -b branch_name
合并分支把其他分支合并到当前分支
git merge --no-ff -m "comment" branch_name
- 要想删除一个分支，必须在已经合并了那个分支的分支上执行删除操作。
git branch -d banch_name
- 强制删除一个分支
git branch -D branch_name
查看所有分支
git branch
如果本地没有远程仓库的某个分支，把远程分支拉取到本地，并且建立连接
git checkout -b branch_name orign/branch_name
从远程分支更新本地分支
推送分支到远程分支把本地分支的更新推送到远程分支(需要先建立连接)；或者在远程仓库没有此分支时，把本地分支推送到远程仓库
git push origin branch_name
使本地分支与远程分支建立连接
git branch --set-upstream branch_name origin/branch_name
删除远程仓库的分支
git push origin --delete branch_name
使用 nvie 开发的Git Flow工具
nvie为Git Flow提供了一套命令行工具，使用它可以更方便的操作Git Flow.
初始化Git Flow
git flow init
在一个git仓库中初始化git flow，会弹出一系列提示信息，跟着做就行了。
在一个非git仓库的文件夹中初始化，会创默认建好需要的分支，没有任何提示
创建feature/release/hotfix/support分支初始化Git Flow会自动创建/指定主要分支，但辅助分支需要开发者手动创建。
查看/创建/完成feature分支
git flow feature
git flow feature start feature_branch_name
git flow feature finish feature_branch_name
start命令，会创建一个新的feature分支；finish命令，会自动合并feature分支到develop分支和master分支，并删除feature分支。
push/pull一个feature分支到远程仓库
git flow feature publish feature_branch_name
git flow feature pull origin feature_branch_name
其他分支 - hotfix/release/support分支的操作与feature分支基本相同，直接去参考官方文档吧。
参考文献：
基于git的源代码管理模型——git flow
Git 常用命令和 Git Flow 梳理
Git flow 分支策略
Git Flow在github的主页
git checkout -- file 在加入到暂存区之前，遗弃修改git reset HEAD file 在提交之前，遗弃暂存区的更改git reset --hard HEAD^ 回退到上一版本git reset --hard commit_id
回退到指定的版本
git mv file newfile 重命名，文件名不区分大小写git rm file 删除文件git remote rename repo new_repo 重命名远程仓库
(责任编辑：美朵)
每日重点推荐
夏医生是自己多年老同事的儿子，国外学成归来做事业，老同事担心儿子诊所刚开，门厅罗雀伤了自尊，便偷偷塞钱给李梅，求她装病去“捧场”。
一周热点文章
在线阅读专题使用git-flow来帮助管理git代码 - 博客频道 - CSDN.NET
貌似掉线的博客
疯狂的键盘
分类：就是笔记
对git不熟悉的我，经常把git提交搞得很乱，导致在master上有许多无用的commit，最终决定好好地看一下git的使用教程，却不小心发现了还有一个git-flow的工具可以帮助我管理好git项目的代码。
git-flow在ubuntu上使用比较简单。首先安装，可以通过apt-get来获取。命令如下：
sudo apt-get install git-flow
如果是在windows下，可以参考这篇文章进行安装：/sunxun/archive/158.html
如果你的git已经装好，则方便多了，下载下面两个地址的文件，并解压出getopt.exe和libintl3.dll放到git的安装目录的bin目录下。
http://sourceforge.net/projects/gnuwin32/files/util-linux/2.14.1/util-linux-ng-2.14.1-bin.zip/download
http://sourceforge.net/projects/gnuwin32/files/util-linux/2.14.1/util-linux-ng-2.14.1-dep.zip/download
然后检出github上gitflow项目，如下命令：
git clone --recursive git:///nvie/gitflow.git进入并执行里面的contrib\msysgit-install.cmd，提示复制成功，就可以了。
接下来是初始化项目。我在我原来的git项目上执行以下命令来进行初始化：
git flow init
它会创建或转换一个新的版本分支结构，当然在初始化的过程中，会问到以下这边问题，我都选择了默认：
Which branch should be used for bringing forth production releases?
Branch name for production releases: [master]
Branch name for &next release& development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
完成之后，通过git branch 命令，可以看到它为我们新建好了一个develop的分支。
接下来我将继续使用，这篇笔记再慢慢补充。
修复一个bug。
git flow hotfix start 3它会创建一个基于master的分支hotfix/3，并切换到当前分支。
当修复完成后，可以执行以下命令：
git flow notfix finish 3
增加一个功能特性
git flow feature start demo
它会创建一个分支feature/demo，并切换到该分支。
当功能完成：git flow feature finish demo它会有feature/demo分支合并到develop分支，然后切换回develop分支，并删除feature/demo分支。
功能完成，要合并到主分支，这时可以执行
git flow release start v0.7.0它会创建一个release/v0.7.0分支，并切换到该分支。
然后在这里进行测试。如果测试没问题，则执行以下命令：
git flow release finish v0.7.0它会将release/v0.7.0分支的内容合并到master分支和develop分支，并且打上tag v0.7.0，然后删除release/v0.7.0分支。
maosidiaoxian
排名：第1028名
Android高级开发群：
Andriod Studio Tech：
（2）（16）（68）（1）（3）（6）（3）（55）（26）（2）（1）（1）
（124085）Posts - 343,
Articles - 3,
Comments - 1741
11:08 by 敏捷的水, ... 阅读,
我们已经从SVN 切换到Git很多年了，现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用。
Git的优点很多，但是这里只列出我认为非常突出的几点。
由于是分布式，所有本地库包含了远程库的所有内容。
优秀的分支模型，打分支以及合并分支，机器方便。
快速，在这个时间就是金钱的时代，Git由于代码都在本地，打分支和合并分支机器快速，使用个SVN的能深刻体会到这种优势。
感兴趣的，可以去看一下Git本身的设计，内在的架构体现了很多的优势，不愧是出资天才程序员Linus (Linux之父) 之手
版本管理的挑战
虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：
如何开始一个Feature的开发，而不影响别的Feature？
由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
哪些分支已经合并回了主干？
如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?
大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。
就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范
Vincent Driessen 同学为了解决这个问题提出了
下面是Git Flow的流程图
上面的图你理解不了？ 没关系，这不是你的错，我觉得这张图本身有点问题，这张图应该左转90度，大家应该就很用以理解了。
Git Flow常用的分支
Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
Release分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
Hotfix分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
Git Flow如何工作
所有在Master分支上的Commit应该Tag
Feature 分支
分支名 feature/*
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留
Release分支
分支名 release/*
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
维护分支 Hotfix
分支名 hotfix/*
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
Git Flow代码示例
a. 创建develop分支
git branch develop
git push -u origin develop
b. 开始新Feature开发
git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature
# 做一些改动
git status
git add some-file
git commit
c. 完成Feature
git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop
git branch -d some-feature
# If you pushed branch to origin:
git push origin --delete some-feature
d. 开始Relase
git checkout -b release-0.1.0 develop
# Optional: Bump version number, commit
# Prepare release, commit
e. 完成Release
git checkout master
git merge --no-ff release-0.1.0
git checkout develop
git merge --no-ff release-0.1.0
git branch -d release-0.1.0
# If you pushed branch to origin:
git push origin --delete release-0.1.0
git tag -a v0.1.0 master
git push --tags
f. 开始Hotfix
git checkout -b hotfix-0.1.1 master
g. 完成Hotfix
git checkout master
git merge --no-ff hotfix-0.1.1
git checkout develop
git merge --no-ff hotfix-0.1.1
git branch -d hotfix-0.1.1
git tag -a v0.1.1 master
git push --tags
Git flow工具
实际上，当你理解了上面的流程后，你完全不用使用工具，但是实际上我们大部分人很多命令就是记不住呀，流程就是记不住呀，肿么办呢？
总有聪明的人创造好的工具给大家用, 那就是Git flow script.
brew install git-flow
apt-get install git-flow
wget -q -O - --no-check-certificate
初始化: git flow init
开始新Feature: git flow feature start MYFEATURE
Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE
获取Publish的Feature: git flow feature pull origin MYFEATURE
完成一个Feature: git flow feature finish MYFEATURE
开始一个Release: git flow release start RELEASE [BASE]
Publish一个Release: git flow release publish RELEASE
发布Release: git flow release finish RELEASE
别忘了git push --tags
开始一个Hotfix: git flow hotfix start VERSION [BASENAME]
发布一个Hotfix: git flow hotfix finish VERSION
Git Flow GUI
上面讲了这么多，我知道还有人记不住，那么又有人做出了GUI 工具，你只需要点击下一步就行，工具帮你干这些事！！！
SourceTree
当你用Git-flow初始化后，基本上你只需要点击git flow菜单选择start feature, release或者hotfix, 做完后再次选择git flow菜单，点击Done Action. 我勒个去，我实在想不到还有比这更简单的了。
目前SourceTree支持Mac, Windows, Linux.
这么好的工具请问多少钱呢？ 免费!!!!
Git flow for visual studio
广大VS的福音
我经常收到邮件问我，他想使用Git, 但是公司还在坚持使用SVN等，问我最么办？ 我的办法是：
第一： 把我这篇文章给他看
第二： 立即找我，加入我们公司，我的邮箱是使用Gitblit对web开发跟踪管理，添加“自动部署”脚本，在push时将网页一并推送到webroot
方法：将以下代码保存为在gitblit/data/groovy/目录，文件名为deploy.groovy（注意此脚本仅适于用Gitblit）
* Copyright .
* Licensed under the Apache License, Version 2.0 (the &License&);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an &AS IS& BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
import com.gitblit.GitBlit
import com.gitblit.Keys
import com.gitblit.models.RepositoryModel
import com.gitblit.models.TeamModel
import com.gitblit.models.UserModel
import com.gitblit.utils.JGitUtils
import com.gitblit.utils.StringUtils
import java.text.SimpleDateFormat
import org.eclipse.jgit.api.CheckoutCommand
import org.eclipse.jgit.api.Git
import org.eclipse.jgit.lib.Repository
import org.eclipse.jgit.lib.RepositoryBuilder
import org.eclipse.jgit.lib.Config
import org.eclipse.jgit.revwalk.RevCommit
import org.eclipse.jgit.transport.ReceiveCommand
import org.eclipse.jgit.transport.ReceiveCommand.Result
import org.eclipse.jgit.util.FileUtils
import org.slf4j.Logger
* Sample Gitblit Post-Receive Hook: localclone
* The Post-Receive hook is executed AFTER the pushed commits have been applied
* to the Git repository.
This is the appropriate point to trigger an
* integration build or to send a notification.
* This script is only executed when pushing to *Gitblit*, not to other Git
* tooling you may be using.
* If this script is specified in *groovy.postReceiveScripts* of gitblit.properties
* or web.xml then it will be executed by any repository when it receives a
If you choose to share your script then you may have to consider
* tailoring control-flow based on repository access restrictions.
* Scripts may also be specified per-repository in the repository settings page.
* Shared scripts will be excluded from this list of available scripts.
* This script is dynamically reloaded and it is executed within it's own
* exception handler so it will not crash another script nor crash Gitblit.
* If you want this hook script to fail and abort all subsequent scripts in the
* chain, &return false& at the appropriate failure points.
* Bound Variables:
Gitblit Server
com.gitblit.GitBlit
repository
Gitblit Repository
com.gitblit.models.RepositoryModel
receivePack
JGit Receive Pack
org.eclipse.jgit.transport.ReceivePack
Gitblit User
com.gitblit.models.UserModel
JGit commands
Collection&org.eclipse.jgit.transport.ReceiveCommand&
Base url for Gitblit
Logs messages to Gitblit
org.slf4j.Logger
clientLogger
Logs messages to Git client
com.gitblit.utils.ClientLogger
* Accessing Gitblit Custom Fields:
def myCustomField = repository.customFields.myCustomField
// Indicate we have started the (&deploy hook triggered by ${user.username} for ${repository.name}&)
def rootFolder = '/opt/www'
def repoName = repository.name
def destinationFolder = new File(rootFolder, StringUtils.stripDotGit(repoName))
def sourceFolder = new File(gitblit.getRepositoriesFolder(), repoName)
(&deploy hook checkout ${sourceFolder.absolutePath} to ${destinationFolder.absolutePath}&)
if (destinationFolder.exists()) {
(&deploy hook checkout begin&)
Repository repo = new RepositoryBuilder()
.setGitDir(sourceFolder)
.setWorkTree(destinationFolder)
(&deploy of repo. ${repo.isBare()}&)
(&deploy of repo. ${repo.getWorkTree()}&)
Git git = new Git(repo)
CheckoutCommand cmd = git.checkout()
cmd.setForce(true)
cmd.setAllPaths(true)
cmd.setName(&master&)
cmd.setStartPoint(&HEAD&)
cmd.call();
git.repository.close()
(&deploy hook checkout ignore&)
(&${repoName} deploy to ${destinationFolder}&)
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：17880次
排名：千里之外
原创：27篇
评论：15条
(1)(1)(1)(1)(1)(2)(3)(1)(1)(1)(1)(3)(1)(1)(1)(2)(6)