首先需要了解一下git hooks，和其它版本控制系统一样，Git 能在特定的重要动作发生时触发自定义脚本。
git hooks
可以参考书籍Pro Git中的这一章 Customizing Git - Git Hooks
hooks有两种：客户端的和服务器端。 客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。hooks 都被存储在 Git 目录下的 hooks 子目录中。 也即绝大部分项目中的 .git/hooks 。 当你用初始化一个新版本库时，Git 默认会在这个目录中放置一些示例脚本。这些示例的名字都是以 .sample 结尾，如果你想启用它们，需要移除这个后缀，当你执行相应的git操作时，脚本就会运行。
客户端hooks
包括committing-workflow hooks, email-workflow scripts, and everything else。需要注意的是客户端 hooks 在clone仓库时并不会复制。
committing-workflow hooks 主要有以下4种，在执行git commit的时候进行检查，有pre-commit、 prepare-commit-msg、 commit-msg 和 post-commit，包括提交前的文件检测、提交信息的检测和提交后的通知等。
email-workflow scripts 使用 git am 命令调用的，如果你需要通过电子邮件接收由 git format-patch 产生的补丁，可以使用这些hooks。
其他hooks 例如 pre-rebase、 post-rewrite、 post-checkout、 post-merge、 pre-push等
服务端hooks
主要看一下服务端hooks，主要有3种
pre-receive
处理来自客户端的推送操作时，最先被调用的脚本是 pre-receive。 它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。 你可以用hooks阻止对引用进行 non-fast-forward 的更新，或者对该推送所修改的所有引用和文件进行访问控制。
update
update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。
post-receive
post-receive 在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。 它接受与 pre-receive 相同的标准输入数据。 它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器，或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。 该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态，所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。
Stash hooks
stash hooks也是类似的，提供了服务端的三种类型的hooks
https://developer.atlassian.com/stash/docs/latest/how-tos/repository-hooks.html
Pre-receive
同git的pre-receive，可以用来阻止使用push来删除分支，或者使用—force来强推分支。在pr进行merge的时候不会生效，可以使用 Merge-checks。
Asynchronous Post-receive
同git的post-receive，不过是异步的，不需要给客户端返回信息，客户端也不会等待服务端返回，体验更好。可以用在通知CI（例如jenkins）服务器
Merge-checks
在进行 pull requests 时，满足条件才可以继续进行。比如限制所有的reviewers必须都approve，或者所有的build都执行成功才可以。
Stash APIs
https://developer.atlassian.com/stash/docs/latest/index.html 是开发文档，其中包括很多开放的API
API是REST架构的，可以通过 深入浅出REST 为啥REST如此重要 了解一下
URI的结构
http://host:port/context/rest/api-name/api-version/path/to/resource
个人仓库为
http://example.com/rest/api/1.0/users/~{userSlug}/repos
Authentication
采用的是HTTP Basic 和 OAuth
可以在Postman里设置，模拟请求
Resources
例如 branch-permissions 的api
/rest/branch-permissions/1.0/projects/{projectKey}/repos/{repositorySlug}/permitted
可以完成branch权限的管理
Branch permission patterns 可以通过不同的pattern管理分支和tag的权限
git hooks补充(摘自Pro Git)
committing-workflow hooks
主要有以下4种，在执行git commit的时候进行检查，包括提交前的文件检测、提交信息的检测和提交后的通知等。
pre-commit
在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 git commit –no-verify 来绕过这个环节。
prepare-commit-msg
钩子在启动提交信息编辑器之前，默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它，动态地插入信息。
commit-msg
接收一个参数，此参数存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出，Git 将放弃提交。
可以用来在提交通过前验证项目状态或提交信息。
post-commit
在整个提交过程完成后运行。 它不接收任何参数，一般用于通知之类的事情。
email-workflow scripts
有三个hooks。 使用 git am 命令调用的，如果你需要通过电子邮件接收由 git format-patch 产生的补丁，可以使用这些hooks。
git am详解
https://git-scm.com/docs/git-am
http://gitbook.liuhui998.com/5_6.html
applypatch-msg
一个参数：包含请求合并信息的临时文件的名字。 如果脚本返回非零值，Git 将放弃该补丁。 你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。
pre-applypatch
运行于应用补丁之后，产生提交之前，所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。
post-applypatch
运行于提交产生之后，是在 git am 运行期间最后被调用。可以用于最后的通知。
其它hooks
pre-rebase
运行于rebase之前，以非零值退出可以中止rebase的过程。 你可以使用这个hook来禁止对已经推送的提交进行rebase。
post-rewrite
被那些会替换提交记录的命令调用，比如 git commit –amend 和 git rebase（不过不包括 git filter-branch）。 它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。 这个钩子的用途很大程度上跟 post-checkout 和 post-merge 差不多。
post-checkout
在 git checkout 成功运行后会被调用。你可以根据你的项目环境用它调整你的工作目录。 其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作。
post-merge
在 git merge 成功运行后会被调用。 你可以用它恢复 Git 无法跟踪的工作区数据，比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。
pre-push
会在 git push 运行期间， 更新了远程引用但尚未传送对象时被调用。 它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。 你可以在推送开始之前，用它验证对引用的更新操作。
pre-auto-gc
会在使用 git gc —auto 进行垃圾回收开始之前被调用。 可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。