3 ms·
Sounds like your team may benefit from pre-commit hooks! Our team has an onboarding script we have every new dev run that (among other things) installs pre-com
by Centigonal 4y ago
Sounds like your team may benefit from pre-commit hooks!
Our team has an onboarding script we have every new dev run that (among other things) installs pre-commit. Our main repo includes hooks for style, max file size, etc.
If there's a style nit, git will yell at you and not accept the commit. If possible, it'll actually correct the style issue (e.g. blackify a python file for you) and you can just stage the updated file.
We still have CI/CD, but that catches other errors, not linting issues. This method has worked pretty well for us so far.
- pornel 4y agoThese hooks must be really high quality — fast and reliable. Otherwise they will get in the way, slowing down development or even breaking git. List of problems include: • the hook runs tools directly on the working directory, and not on the stage/index, so it lints against a mixed version of the code, and not what is actually being committed. • the hook tries to fix the problem above, but doesn't understand submodules and screws them up • a new version of a linter adds a new warning that fires on existing code, and now nobody can commit anything without disabling the hook. • hook expects the tools to be in PATH that isn't set as expected when git is used via IDE or some other GUI tool and so on.