Git Hooks are scripts that can be run in response to certain actions. Git Hooks are defined for each repository within your system. By design, the Hooks are not transmitted between repositories. The idea behind the design is that an evil actor can't introduce automated code to anyone's machine. I'm all in favor of this. However, as you start to work with Git Hooks, you'll quickly recognize that this is something you'll need to share with your team. Let's talk about a specific example.

Flyway Validate

One feature I find myself constantly using in Flyway is the 'validate' command. The concept is simple: test the scripts I have to ensure they'll work against our database. You can run validate against an existing database, or, with a little magic, you can run it against a blank database. However, from a source control standpoint, the idea is pretty clear, test this code before I check it in to source control. As outlined originally in this Flyway blog post, you can put Git Hooks to work on this process.

The concept is simple, but the execution is not as simple as it immediately appears. Let's take the example Hook for pre-commit:

#!/bin/sh 
if flyway validate -url=jdbc:h2:mem:dummydb \ 
    -locations=filesystem:/mnt/c/src/sandbox/gitHookDemo/ \ 
    -ignorePendingMigrations=true; then 
    echo Flyway validation successful 
    exit 0 
else 
    echo Flyway validation failed 
    exit 1 
fi

The idea is simple. Validate my code prior to adding it to source control. We do this using an empty H2 database and the command to -ignorePendingMigrations. It works. The issue is neither the concept nor the command. The issue is the path:

/mnt/c/src/sandbox/gitHookDemo/

This is all well and good if my path is exactly the same. However, what happens if, for example, we're working on an AWS RDS implementation of PostgreSQL. You're developing in your preferred environment on your Macbook and I'm happily ensconced on my Surface laptop. If we try to share this Git Hook, we're going to have problems.

Relative Path

Thinking this through, we have options. First, I could simply have a different Hook than you. Of course, this means that as we expand the scope and complexity of our Hooks, I'm spending a ton of time editing. Alternatively, we can use relative paths to see how that works. I tested this:

#!/bin/sh
if flyway validate -url=jdbc:h2:mem:dummydb \
        -locations=filesystem:../gitHookDemo \
        -ignorePendingMigrations=true; then
    echo Flyway validation successful
    exit 0
else
    echo Flyway validation failed
    exit 1
fi

It worked perfectly, and, I was able to share it with others. It's just a question of understanding where the Git Hooks get executed from and modifying the path appropriately.

Conclusion

There's a lot more to sharing Git Hooks between team members than is outlined here. However, if you're just getting started with Git Hooks, as you write your scripts, start writing them with sharing in mind. As you build functionality through Git and implement it as part of your fundamental DevOps processing, you're going to want to share this with the team.