git钩子

定义:
  钩子:由事件触发的函数

分类:
  客户端钩子:由诸如提交和合并这样的操作触发
  服务器端钩子:由诸如接收被推送的提交这样的联网操作触发

安装:
  a.钩子都被存储在 .git 目录下的 hooks 子目录中
  b.当 git init 初始化一个新版本库时,默认会在这个目录中放置一些示例脚本
  c.任何正确命名的可执行脚本都可以正常使用(Ruby、Python、shell或其它语言)
  d.这些示例的名字都是以.sample 结尾,如果想启用它们,移除这个后缀就可以了

客户端钩子:
  提交工作流钩子:
    pre-commit 钩子在键入提交信息前运行
      a.用于检查即将提交的快照,例如,检查是否有所遗漏,确保测试运行,以及核查代码
      b.如果该钩子以非零值退出,Git 将放弃此次提交
      c.可以用 git commit --no-verify 来绕过这个环节
      
    prepare-commit-msg 钩子在启动提交信息编辑器之前,默认信息被创建之后运行
      a.入参:存有当前提交信息的文件的路径、提交类型和修补提交的提交的SHA-1校验
      b.它允许你编辑提交者所看到的默认信息
      c.对那些会自动产生默认信息的提交可以结合提交模板来使用它,动态地插入信息

    commit-msg 钩子在提交之后运行
      a.入参:存有当前提交信息的文件的路径
      b.如果该钩子以非零值退出,Git 将放弃此次提交
      c.可以用来在提交通过前验证项目状态或提交信息

    post-commit 钩子在整个提交过程完成后运行
      a.不接收任何参数
      b.通过 git log -1 HEAD 来获得最后一次的提交信息
      c.一般用于通知之类的事情

  电子邮件工作流钩子:
    a.电子邮件工作流钩子都是由 git am 命令调用
    b.如果需要通过电子邮件接收由 git format-patch 产生的补丁,这些钩子也许用得上

    applypatch-msg 钩子 在git am 运行前被调用
      a.接收单个参数:包含请求合并信息的临时文件的名字
      b.如果脚本返回非零值,Git 将放弃该补丁
      c.可以用该脚本来确保提交信息符合格式,或直接用脚本修正格式错误

    pre-applypatch 钩子 在git am 运行期间被调用
      a.他正好运行于应用补丁之后,产生提交之前,所以可以用它在提交前检查快照
      b.可以用这个脚本运行测试或检查工作区。
      c.如果有什么遗漏,或测试未能通过,脚本以非零值退出,中断 git am 的运行,补丁就不会被提交

    post-applypatch 钩子 运行于提交产生之后
      a.可以用它把结果通知给一个小组或所拉取的补丁的作者
      b.但无法用它停止打补丁的过程

  其他钩子:
    pre-rebase 钩子 变基之前被调用
      a.以非零值退出可以中止变基的过程
      b.可以使用这个钩子来禁止对已经推送的提交变基

    post-rewrite 钩子被那些会替换提交记录的命令调用,
      a.例如git commit --amend 和 git rebase(不包括 git filter-branch)
      b.它唯一的参数是触发重写的命令名,同时从标准输入中接受一系列重写的提交记录
      c.用途很大程度上跟 post-checkout 和 post-merge 差不多。

    post-checkout 钩子在 git checkout 成功运行后会被调用
      a.可以根据你的项目环境用它调整你的工作目录
      b.例如:放入大的二进制文件、自动生成文档或进行其他类似这样的操作。

    post-merge 钩子在 git merge 成功运行后会被调用
      a.可以用它恢复 Git 无法跟踪的工作区数据,例如:权限数据。
      b.可以用来验证某些在 Git 控制之外的文件是否存在,对这些文件进行处理。

    pre-push 钩子在 git push 之前调用。
      a.它接受远程分支的名字和位置作为参数,同时从标准输入中读取一系列待更新的引用
      b.可以在推送开始之前,用它验证对引用的更新操作
      c.一个非零的退出码将终止推送过程

    pre-auto-gc 钩子会在垃圾回收开始之前被调用
      a.git的一些日常操作在运行时,偶尔会调用 git gc --auto 进行垃圾回收。
      b.可以用它来提醒你现在要回收垃圾了,或者依情形判断是否要中断回收。

说明:克隆某个版本库时,它的客户端钩子 并不 随同复制。 如果需要靠这些脚本来强制维持某种策略,可以在服务器端实现这一功能

服务器端钩子:
  pre-receive 处理来自客户端的推送操作时,最先被调用的脚本是 pre-receive
    a.它从标准输入获取一系列被推送的引用。
    b.如果它以非零值退出,所有的推送内容都不会被接受
    c.可以用这个钩子阻止对引用进行非快进(non-fast-forward)的更新
    d.可以对该推送所修改的所有引用和文件进行访问控制。

  update
    a.update 脚本和 pre-receive 脚本十分类似,不同之处在于它会为每一个准备更新的分支各运行一次
    b.假如同时向多个分支推送内容,pre-receive 只运行一次,update 会每一个被推送的分支运行一次
    c.接受三个参数:引用的名字(分支),推送前引用指向的SHA-1值,推送内容的SHA-1值
    d.如果 update 脚本以非零值退出,只有相应的那一个引用会被拒绝;其余的依然会被更新。

  post-receive 在整个过程完结以后运行
    a.可以用来更新其他系统服务或者通知用户,例如:给某个邮件列表发信,通知持续集成的服务器
    b.该脚本无法终止推送进程
    c.不过客户端在它结束运行之前将保持连接状态

时间: 2024-11-02 18:55:27

git钩子的相关文章

Git 钩子

1. 概念概述 1.1. 安装钩子 1.2. 脚本语言 1.3. 钩子的作用域 2. 本地钩子 2.1. 预提交钩子 Pre-Commit 2.2. 准备提交信息钩子 Prepare Commit Message 2.3. 提交信息钩子 Commit Message 2.4. 提交后钩子 Post-Commit 2.5. 切换后钩子 Post-Checkout 2.6. 预衍合钩子 Pre-Rebase 3. 服务端钩子 3.1. 预接收钩子 Pre-Receive 3.2. 更新钩子 Upda

利用git钩子,使用python语言获取提交的文件列表

项目有个需求,需要获取push到远程版本库的文件列表,并对文件进行特定分析.很自然的想到,要利用git钩子来触发一个脚本,实现获取文件列表的功能.比较着急使用该功能,就用python配合一些git命令写了一个脚本出来,等想到更好的方法后再对脚本进行修改. #!/usr/bin/env python #coding=utf-8 ''' 该脚本在pre-receive或post-receive钩子中被调用,也可以直接将该文件作为git的钩子使用 若钩子为shell脚本,则需要加入以下代码调用该脚本:

[转] 利用git钩子,使用python语言获取提交的文件列表

项目有个需求,需要获取push到远程版本库的文件列表,并对文件进行特定分析.很自然的想到,要利用git钩子来触发一个脚本,实现获取文件列表的功能.比较着急使用该功能,就用python配合一些git命令写了一个脚本出来,等想到更好的方法后再对脚本进行修改. #!/usr/bin/env python #coding=utf-8 ''' 该脚本在pre-receive或post-receive钩子中被调用,也可以直接将该文件作为git的钩子使用 若钩子为shell脚本,则需要加入以下代码调用该脚本:

git钩子不同步报错

error: Untracked working tree file '' would be overwritten by merge. git 钩子目录执行:git reset --hard HEAD    git clean -f -d    git pull

服务端CVS本地Git的版本控制:利用git钩子自定义工作流

请以解决问题为核心,不要为了用技术而用技术. 公司各个项目有CVS.SVN.HG.Git等多版本管理工具. 但CVS确实太老了,十分不便,由于历史原因公司的部分旧代码还都是用CVS来管理,恰恰是我目前在用的- -|||.但是我们可以在本地使用Git来方便代码的管理.因为Git作为分布式版本管理系统,本身local端就是完备的. 如果是用SVN.HG等版本控制系统,有git-svn等解决方案可以不改变服务端而非常方便的在本地用git,但CVS并没有找到现成的方法-,可能确实太老了吧! 最近终于想到

用 git 钩子,检测代码规范性(eslint、standard)

最终实现效果说明:用 git commit 提交代码之前,利用 pre-commit git 钩子,实现代码规范检测(eslint.standard 规范),符合规范之后才可以提交到 git 仓库.这样在团队合作开发时,可以统一代码风格,如果某些同志代码不符合规范,是无法进行提交代码的. 我的demo地址:demo地址 规范doc:standard规范eslint规范 git 钩子git 钩子 那么问题来了,这种验证是如何实现的呢?! 请确保已经安装了: node | npm | git 安装传

git 钩子配置

准备代码 php开启    popen() shell_exec()   搜索:disable_functions 关闭安全模式 ssh免秘钥传数据

比Gitlab更易搭建的自助Git服务———gogs!

大家都认为Gitlab是一个很棒的Git托管服务,几乎像GitHub一样强大.但是,还有一款产品能够和Gitlab/Github媲美且操作更简单,没错,它就是Gogs.该项目沿用了GitHub Go 语言,而且Gogs的四位主要开发者都是中国人哦,小编我的自豪感油然而生啊! Gogs是什么?   Gogs是一款极易搭建的自助 Git 服务.它的目标是打造一个用最简单.最快速.最轻松的方式搭建自助 Git 服务.使用 Go 语言开发让Gogs能够通过独立的二进制进行分发,并且支持 Go 语言支持的

Git管理Puppet打造统一配置管理

一.介绍 1)运维工作流程 大数据时代高伸缩性.容错性的特点给运维提出了更高的要求.系统管理不再是疲于安装操作系统.对系统参数进行逐一配置与优化.打补丁.安装软件.配置软件.添加某个服务的时代.为了提高效率.避免重复劳动.减少错误.积累知识,系统管理员都已开始做一些局部的自动化工作.但这些还远不够, 为了满足运维需求,需要统一配置管理. 2)自己实现自动化:git+puppet Puppet采用了非常简单的C/S架构,所有数据的交互都通过SSL进行,以保证安全. Git是一个开源的分布式版本控制