Svn Git hooks scripts(版本管理工具的挂钩脚本)

Svn Git hooks scripts

简介

      SVN全名Subversion，是一款集中式的代码版本控制系统，早期Linux/eCos开发时如果对多人协同的要求不是很高的话，使用的是这个管理软件还是比较方便的。

Git 是一款分布式版本控制系统（Distributed Version Control System，简称 DVCS ）。Android的出现扩大Git的使用范围，由于Android预设就是需要多人协同，原有的集中式的版本管理系统已经不能满足需求，所以Android的开发团队选择使用Git进行代码的管理。

Svn hook scripts

       关于hook scripts的详细说明可以参考客户端（TortoiseSVN）的帮助文档，这里只做简单的介绍。

博客文章：http://floscc.blog.51cto.com/1880249/533394

服务端的挂钩脚本(hook scripts)

     Hookscripts(挂钩脚本)是在代码版本发生变化时所触发的程序，比如在创建一个新的代码版本或者修改版本控制的属性。每个挂钩(hook)都能拿到足够的信息标明触发挂钩(hook)的是什么事件，运行的目标平台，和触发挂钩的用户名称等。Svn的客户端可以根据挂钩程序的输出或者返回值决定下一步的该做什么（可以停止、继续、暂停用户的行为）。

       挂钩脚本会被管理代码仓库的服务器执行，当然客户端（TortoiseSVN）也允许配置挂钩脚本，然后再特定的事件下触发脚本。

       代码仓库的hooks目录下可以找到挂钩脚本的范例。这些范例脚本可以在Unix/Linux平台的服务器上执行，但是如果使用的使用windows 服务器的话需要做一些修改。Windows下的挂钩可以是一个批处理文件(.bat)或者可执行文件(.exe).下面给出一个可以在windows服务器上执行的挂钩脚本。

rem Only allow log messages to be changed.
if "%4" == "svn:log" exit 0
echo Property '%4' cannot be changed >&2
exit 1

注意事项：如果你想要在你的屏幕上显示挂钩脚本中的打印信息，你就必须交打印信息输出到stderr。

 

客户端挂钩脚本（hook scripts）

       你可以在客户端设置挂钩脚本，一旦配置成功，那么脚本就会在特定的事件下被触发，与服务器端的脚本不同，客户端的脚本是在客户端本地执行的。

       一个应用程序可能希望在提交代码之后通过挂钩脚本重新编译代码或者更新版本号都是可以的。

       如下如所示，你可以在客户端指定脚本以及代码工作目录的用于特定代码块触发挂钩脚本。默认请款下客户端没有任何的hook scripts，需要通过图2.2-1所示添加脚本，一共有6中脚本类型可供选择：

Start-commit
在提交代码的对话框出现之前被调用。

Pre-commit
在点击OK提交代码的时候被调用，此行为会在commit代码到服务器之前被调用，所以你可以使用此脚本检查commit log或者修改的代码是否符合规范。

Post-commit
在代码提交到服务器之前被调用，通常可以用来提示用户提交代码是成功还是失败。

Start-update
在 update-to-revision 对话框显示之前被调用。

Pre-update
在“update”命令实际执行之前被调用。

Post-update
在“update”命令执行完成后被调用，主要用于提示“update”是否成功。



图 2.2-1
 


图2.2-2
 

Git hook scripts（挂钩脚本）

      和其他版本控制系统一样，当某些重要事件发生时，Git 以调用自定义脚本。有两组挂钩：客户端和服务器端。客户端挂钩用于客户端的操作，如提交和合并。服务器端挂钩用于Git 服务器端的操作，如接收被推送的提交。你可以随意地使用这些挂钩，下面会讲解其中一些。

 

安装一个挂钩

      挂钩都被存储在 Git 目录下的hooks子目录中，即大部分项目中的.git/hooks。 Git 默认会放置一些脚本样本在这个目录中，除了可以作为挂钩使用，这些样本本身是可以独立使用的。所有的样本都是shell脚本，其中一些还包含了Perl的脚本，不过，任何正确命名的可执行脚本都可以正常使用 — 可以用Ruby或Python，或其他。在Git 1.6版本之后，这些样本名都是以.sample结尾，因此，你必须重新命名。在Git 1.6版本之前，这些样本名都是正确的，但这些样本不是可执行文件。把一个正确命名且可执行的文件放入
Git 目录下的hooks子目录中，就可以激活该挂钩脚本，因此，之后他一直会被Git 调用。随后会讲解主要的挂钩脚本。

 

客户端挂钩

      有许多客户端挂钩，以下把他们分为：提交工作流挂钩、电子邮件工作流挂钩及其他客户端挂钩。

提交工作流挂钩
有 4个挂钩被用来处理提交的过程：

pre-commit挂钩在键入提交信息前运行，被用来检查即将提交的快照，例如，检查是否有东西被遗漏，确认测试是否运行，以及检查代码。当从

该挂钩返回非零值时，Git 放弃此次提交，但可以用git commit --no-verify来忽略。该挂钩可以被用来检查代码错误（运行类似lint的程序），检查尾部空白（默认挂钩是这么做

的），检查新方法（译注：程序的函数）的说明。

 

prepare-commit-msg挂钩在提交信息编辑器显示之前，默认信息被创建之后运行。因此，可以有机会在提交作者看到默认信息前进行编辑。该挂钩接收一些选项：拥有提交信息的文件路径，提交类型，如果是一次修订的话，提交的SHA-1校验和。该挂钩对通常的提交来说不是很有用，只在自动产生的默认提交信息的情况下有作用，如提交信息模板、合并、压缩和修订提交等。可以和提交模板配合使用，以编程的方式插入信息。

 

commit-msg挂钩接收一个参数，此参数是包含最近提交信息的临时文件的路径。如果该挂钩脚本以非零退出，Git 放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。本章上一小节已经展示了使用该挂钩核对提交信息是否符合特定的模式。

 

post-commit挂钩在整个提交过程完成后运行，他不会接收任何参数，但可以运行git log-1 HEAD来获得最后的提交信息。总之，该挂钩是作为通知之类使用的。

 

      提交工作流的客户端挂钩脚本可以在任何工作流中使用，他们经常被用来实施某些策略，但值得注意的是，这些脚本在clone期间不会被传送。可以在服务器端实施策略来拒绝不符合某些策略的推送，但这完全取决于开发者在客户端使用这些脚本的情况。所以，这些脚本对开发者是有用的，由他们自己设置和维护，而且在任何时候都可以覆盖或修改这些脚本。

 

服务器端挂钩

      除了客户端挂钩，作为系统管理员，你还可以使用两个服务器端的挂钩对项目实施各种类型的策略。这些挂钩脚本可以在提交对象推送到服务器前被调用，也可以在推送到服务器后被调用。推送到服务器前调用的挂钩可以在任何时候以非零退出，拒绝推送，返回错误消息给客户端，还可以如你所愿设置足够复杂的推送策略。

pre-receive 和 post-receive

处理来自客户端的推送（push）操作时最先执行的脚本就是pre-receive 。它从标准输入（stdin）获取被推送引用的列表；如果它退出时的返回值不是0，所有推送内容都不会被

接受。利用此挂钩脚本可以实现类似保证最新的索引中不包含非fast-forward类型的这类效果；抑或检查执行推送操作的用户拥有创建，删除或者推送的权限或者他是否对将要修改的每一个文件都有访问权限。

post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。它接受与pre-receive相同的标准输入数据。应用实例包括给某邮件列表发信，通知

实时整合数据的服务器，或者更新软件项目的问题追踪系统 —— 甚至可以通过分析提交信息来决定某个问题是否应该被开启，修改或者关闭。该脚本无法组织推送进程，不过客户端在它完成运行之前将保持连接状态；所以在用它作一些消耗时间的操作之前请三思。