|
| 1 | +# Contributing to ai-git-hooks |
| 2 | + |
| 3 | +Thank you for your interest in contributing! This document covers everything |
| 4 | +you need to know to get changes merged. |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +## How to contribute |
| 9 | + |
| 10 | +All changes — including from maintainers — must go through a pull request. Direct pushes to `main` are not allowed. Every PR runs automated checks via GitHub Actions to validate shell syntax and script integrity before merging. |
| 11 | + |
| 12 | +--- |
| 13 | + |
| 14 | +## Development setup |
| 15 | + |
| 16 | +```bash |
| 17 | +git clone git@github.com:rootstrap/ai-git-hooks.git |
| 18 | +cd ai-git-hooks |
| 19 | +``` |
| 20 | + |
| 21 | +No dependencies to install — the project is pure shell scripts and YAML. |
| 22 | + |
| 23 | +--- |
| 24 | + |
| 25 | +## Commit messages |
| 26 | + |
| 27 | +This project uses [Conventional Commits](https://www.conventionalcommits.org). |
| 28 | +`release-please` reads your commit messages to determine version bumps and |
| 29 | +generate the changelog automatically, so following the convention is important. |
| 30 | + |
| 31 | +| Prefix | When to use | Version bump | |
| 32 | +|---|---|---| |
| 33 | +| `fix:` | Bug fix in the hook or installer | Patch | |
| 34 | +| `feat:` | New feature or template | Minor | |
| 35 | +| `feat!:` or `fix!:` | Breaking change | Major | |
| 36 | +| `docs:` | Documentation only | None | |
| 37 | +| `chore:` | Maintenance, config, CI | None | |
| 38 | +| `refactor:` | Code restructure, no behaviour change | None | |
| 39 | + |
| 40 | +Examples: |
| 41 | +``` |
| 42 | +feat: add python template |
| 43 | +fix: handle filenames with spaces in tool runner |
| 44 | +docs: add troubleshooting section to README |
| 45 | +feat!: require Claude Code CLI — remove fallback to allow push |
| 46 | +``` |
| 47 | + |
| 48 | +--- |
| 49 | + |
| 50 | +## What you can contribute |
| 51 | + |
| 52 | +### Adding a new template |
| 53 | + |
| 54 | +Templates live in `templates/` and are downloaded by `install.sh` when a user |
| 55 | +passes `--template <name>`. To add one: |
| 56 | + |
| 57 | +1. Create `templates/<name>.yml` based on an existing template |
| 58 | +2. Populate the `tools:` section with the stack's standard linters and test runners |
| 59 | +3. Add appropriate `ignore_paths:` for generated or vendored files |
| 60 | +4. Add a row to the templates table in `README.md` |
| 61 | +5. Add the new template name to the `--template` usage comment in `install.sh` |
| 62 | + |
| 63 | +Keep templates self-contained — no inheritance, no references to other files. |
| 64 | +Each template should be a ready-to-use starting point that a developer can |
| 65 | +commit as-is and customise from there. |
| 66 | + |
| 67 | +### Fixing the hook script |
| 68 | + |
| 69 | +`hook/pre-push` has been hardened over many iterations. Before making changes: |
| 70 | + |
| 71 | +- Run `bash -n hook/pre-push` to validate syntax before committing |
| 72 | +- Avoid `eval`, heredoc variable expansion, and unquoted variable interpolation |
| 73 | +- File lists must always be passed as arrays, never as interpolated strings |
| 74 | +- Test on both macOS (BSD tools) and Linux (GNU tools) if possible — `sed`, |
| 75 | + `grep`, and `printf` behave differently between them |
| 76 | + |
| 77 | +### Fixing the installer |
| 78 | + |
| 79 | +`install.sh` follows the same shell safety rules as the hook. Additionally: |
| 80 | +- It must work when piped through `bash` (`curl ... | bash`) |
| 81 | +- It must not assume any tools beyond `bash`, `curl`, and `git` are available |
| 82 | + |
| 83 | +--- |
| 84 | + |
| 85 | +## Testing your changes |
| 86 | + |
| 87 | +There is no automated test suite yet. To test manually: |
| 88 | + |
| 89 | +```bash |
| 90 | +# Validate shell syntax |
| 91 | +bash -n hook/pre-push |
| 92 | +bash -n install.sh |
| 93 | + |
| 94 | +# Test the installer locally (from inside a git repo) |
| 95 | +bash install.sh --template node |
| 96 | + |
| 97 | +# Test the hook by installing it and making a push |
| 98 | +bash install.sh --template node |
| 99 | +git push |
| 100 | +``` |
| 101 | + |
| 102 | +For template changes, install the template into a representative project and |
| 103 | +verify the configured tools run correctly against changed files. |
| 104 | + |
| 105 | +--- |
| 106 | + |
| 107 | +## Pull request checklist |
| 108 | + |
| 109 | +- [ ] `bash -n hook/pre-push` passes with no output |
| 110 | +- [ ] `bash -n install.sh` passes with no output |
| 111 | +- [ ] Commit messages follow Conventional Commits |
| 112 | +- [ ] New templates include all keys from an existing template |
| 113 | +- [ ] `README.md` updated if a new template was added |
| 114 | +- [ ] `install.sh` usage comment updated if a new template was added |
| 115 | + |
| 116 | +--- |
| 117 | + |
| 118 | +## Releases |
| 119 | + |
| 120 | +Releases are fully automated via `release-please`. When your PR is merged to |
| 121 | +`main`, release-please analyses the commit messages and opens a Release PR if |
| 122 | +there is anything releasable. Merging the Release PR creates the GitHub Release |
| 123 | +and git tag automatically — you don't need to do anything manually. |
0 commit comments