{"componentChunkName":"component---src-templates-post-jsx","path":"/blog/012-git-hooked/","result":{"data":{"markdownRemark":{"html":"

There are many ways to ensure code quality, often in some form of linting and formatting tools alongside a CI tool (TravisCI, Jenkins, Bitbucket pipelines, etc). Something small like a missing semi-colon or inconsistent spacing may not change how your code runs in development, but once you minify for production it could cause errors.

\n

So what if you want to ensure your code passes before you push and blast out that CI build error on Slack, without having to remember to run your linting or code formatting tools manually?

\n

Enter: Git hooks.

\n

Git hooks are scripts that are run based on triggers that get fired at various points in your Git workflow, most commonly before or after committing, pushing, or receiving code. Since this is Javascript January, we’ll stick to the theme, but you can use these same patterns for any language or project you may be working on. This post assumes that you know about linting, especially in Javascript land. If not, check out ESLint and Prettier, my favorite linter and formatter.

\n

If you’re already a Git hook whiz, skip ahead to check out Husky to learn about setting up hooks through your project's package.json.

\n

How to Use a Git Hook

\n

Your git repository is automatically initialized with some example hooks. They live in the root of your repository inside the .git/hooks directory and are named based on the type of trigger you want to run the script on. Your script file can be any executable, though we’ll use shell scripts for our examples.

\n

Here’s an example of the default git hooks:

\n
.git/hooks\n├── applypatch-msg.sample\n├── commit-msg.sample\n├── post-checkout\n├── post-update.sample\n├── pre-applypatch.sample\n├── pre-commit.sample\n├── pre-push.sample\n├── pre-rebase.sample\n├── pre-receive.sample\n├── prepare-commit-msg.sample\n└── update.sample
\n

To use a git hook, simply create the script and make sure it’s executable (chmod +x <filename>). If you’re using one of the sample files, make sure to remove the .sample extension.

\n

Pro-tip: If you want to run the same script on different triggers, simply create the first trigger script and symlink the duplicates.

\n

Your First Git Hooks

\n

The following two examples are a couple of my go-to hooks that any Javascript project I’m working on has. Simply add these to your .git/hooks directory in the appropriate file and make sure the scripts are executable.

\n

Lint and Format Your Code before committing

\n

This hook runs before you commit your code and will only run on your staged Javascript files. It runs Prettier for code formatting then runs ESLint to check for any linting errors. If it passes, your commit will go through. Otherwise, it will alert you and stop the commit process so you can make changes.

\n
#!/bin/sh\n# pre-commit\n\nSTAGED_JS_FILES=$(git diff --cached --name-only --diff-filter=ACM "*.js" "*.jsx" | tr '\\n' ' ')\n[ -z "$STAGED_JS_FILES" ]\n\n# Git pre commit hook. ---------------------------------------------------------\n# Runs Prettier on staged .js files\necho "** Formatting Javascript files..."\n# Prettify all staged .js files\necho "$STAGED_JS_FILES" | xargs ./node_modules/.bin/prettier --write\n# Add back the modified/prettified files to staging\necho "$STAGED_JS_FILES" | xargs git add\n\n\n# Git pre commit hook. ---------------------------------------------------------\n# Runs ESLint on staged .js or .jsx files\n# STAGED_JS_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep ".js\\{0undefined1\\}$")\nRED='\\033[1;31m'\nGREEN='\\033[0;32m'\nNC='\\033[0m'\nPASS=true\n\nif [[ "$STAGED_JS_FILES" = "" ]]; then\n  echo "\\n** No Javascript files are currently staged."\n  exit 0\nfi\n\necho "\\n** Linting Javascript files..."\nfor FILE in $STAGED_JS_FILES\ndo\n  ./node_modules/.bin/eslint "$FILE"\n\n  if [[ "$?" != 0 ]]; then\n    PASS=false\n  fi\ndone\n\nif ! $PASS; then\n  echo "\\n${RED}COMMIT FAILED:${NC}\\n\\tYour commit contains files that should pass ESLint but do not. Please fix the ESLint errors and try again.\\n\\tTo override this validationundefined use --no-verify"\n  exit 1\nelse\n  echo "\\n${GREEN}COMMIT SUCCEEDED${NC}"\nfi\n\nexit $?
\n

Checking Dependencies When Checking Out

\n

This hook runs after you checkout a new branch or commit. It checks to see if your package.json has changed in order to check if any dependencies differ. This works great if you’re working on a feature branch that has new dependencies and you need to switch around. It looks for changes in the whole file and doesn’t account for differences in things like version numbers, so keep that in mind.

\n
#!/bin/bash\n# post-checkout\n\n# Git post checkout hook. ------------------------------------------------------\n# Reminds you to update requirementsundefined if necessary\n\nPREVIOUS_HEAD=$1\nNEW_HEAD=$2\nBRANCH_SWITCH=$3\n\nif [ $BRANCH_SWITCH == "1" -a $PREVIOUS_HEAD != $NEW_HEAD ]; then\n    # Start from the repository root.\n    cd ./$(git rev-parse --show-cdup)\n\n    # Check if requirements have been updated - npm/yarn\n    REQUIREMENTS=`git diff $PREVIOUS_HEAD $NEW_HEAD --name-status | grep "package.json"`\n    if [ $? -eq "0" ]; then\n        echo "\\nThe requirements for this project may have changed. Update dependencies by running:"\n        echo "  yarn install"\n    fi\nfi
\n

Managing Git Hooks

\n

Manual Hook Wrangling

\n

Manually managing your git hooks is one of easiest way to get started, but makes sharing hooks a bit more difficult (don't worry, we'll talk about tips for this later).\nGit hooks can be easily managed locally by using a .git-template directory. You can store all of your “default” scripts inside of your template directory and they will automatically be added to your repository each time you run a git init, as long as an existing hook with the same name doesn’t already exist. You can run git init either when starting a project or in an existing project to grab any new Git hooks.

\n

Sharing Git Hooks

\n

The traditional way of managing Git hooks has some drawbacks, particularly that since they’re stored in your .git directory by default. This means they aren’t tracked in your repository.

\n

You could set up a system where your hooks are tracked outside of your .git directory, say in a .hooks directory, then set up a script to symlink your files into your .git/hooks directory (check out a working example here). Alternatively, you can configure Git to simply pull hooks from a different directory altogether by running git config core.hooksPath .hooks (check out another example here).

\n

Side-Stepping Git Hooks Altogether

\n

If you’ve gone through the trouble of setting up linting or code formatting, you’ve probably already set up a script to run with something like npm run lint. With the help of a tool called Husky, we can leverage our scripts that we’ve already set up by using them as Git hooks.

\n

First, install Husky:\nnpm install husky --save-dev

\n

Then add your existing scripts as triggers in your package.json:

\n
{\n  \"scripts\": {\n    \"lint\": \"eslint --ext js --ext jsx src\",\n    \"format\": \"prettier 'src/**/*.{js,jsx}' --write\",\n    \"precommit\": \"npm run lint && npm run format\"\n  },\n  ...\n}
\n

That’s it! Husky will manage all of your Git hooks for you and will run your lint and format command as a pre-commit hook.

\n

For more information, check out the Git documentation on Git hooks and check out the demo repository.

","timeToRead":6,"excerpt":"There are many ways to ensure code quality, often in some form of linting and formatting tools alongside a CI tool (TravisCI, Jenkins…","frontmatter":{"title":"Git Hooked","cover":"https://images.unsplash.com/photo-1495482237874-2abe1e1c92dc?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=934&q=80","date":"2018-01-27","category":"tutorial","tags":["git","git hooks"]},"fields":{"slug":"/blog/012-git-hooked/","date":"2018-01-27T07:00:00.000Z"}}},"pageContext":{"slug":"/blog/012-git-hooked/"}}}