mirror of
https://github.com/jbranchaud/til
synced 2026-01-05 08:08:02 +00:00
Add Skip Pre-Commit Hooks as a git til
This commit is contained in:
@@ -10,7 +10,7 @@ pairing with smart people at Hashrocket.
|
|||||||
|
|
||||||
For a steady stream of TILs, [sign up for my newsletter](https://tinyletter.com/jbranchaud).
|
For a steady stream of TILs, [sign up for my newsletter](https://tinyletter.com/jbranchaud).
|
||||||
|
|
||||||
_1045 TILs and counting..._
|
_1046 TILs and counting..._
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -277,6 +277,7 @@ _1045 TILs and counting..._
|
|||||||
- [Show What Is In A Stash](git/show-what-is-in-a-stash.md)
|
- [Show What Is In A Stash](git/show-what-is-in-a-stash.md)
|
||||||
- [Single Key Presses in Interactive Mode](git/single-key-presses-in-interactive-mode.md)
|
- [Single Key Presses in Interactive Mode](git/single-key-presses-in-interactive-mode.md)
|
||||||
- [Skip A Bad Commit When Bisecting](git/skip-a-bad-commit-when-bisecting.md)
|
- [Skip A Bad Commit When Bisecting](git/skip-a-bad-commit-when-bisecting.md)
|
||||||
|
- [Skip Pre-Commit Hooks](git/skip-pre-commit-hooks.md)
|
||||||
- [Staging Changes Within Vim](git/staging-changes-within-vim.md)
|
- [Staging Changes Within Vim](git/staging-changes-within-vim.md)
|
||||||
- [Staging Stashes Interactively](git/staging-stashes-interactively.md)
|
- [Staging Stashes Interactively](git/staging-stashes-interactively.md)
|
||||||
- [Stash Everything](git/stash-everything.md)
|
- [Stash Everything](git/stash-everything.md)
|
||||||
|
|||||||
30
git/skip-pre-commit-hooks.md
Normal file
30
git/skip-pre-commit-hooks.md
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
# Skip Pre-Commit Hooks
|
||||||
|
|
||||||
|
Projects can choose to adopt pre-commit hooks as part of their contribution
|
||||||
|
workflow. These hooks can help enforce project standards like ensuring a set of
|
||||||
|
changes are formatted and linting properly. These can be set up with a tool
|
||||||
|
like [husky](https://github.com/typicode/husky) or with a custom script.
|
||||||
|
|
||||||
|
As you're working on a feature branch, you can and should make frequent
|
||||||
|
checkpoint commits like a climber puts
|
||||||
|
[pitons](https://en.wikipedia.org/wiki/Piton#:~:text=In%20climbing%2C%20a%20piton%20(%2F,assist%20progress%20in%20aid%20climbing.)
|
||||||
|
into the rock face. These are anchor points that reduce the risk of losing
|
||||||
|
work. They make it easier and safer to return to a point in time when your code
|
||||||
|
was in a "good" state.
|
||||||
|
|
||||||
|
If your checkpoint commit isn't conforming to all the pre-commit hook checks,
|
||||||
|
you can choose to skip the checks and commit anyway. To do this, tack on the
|
||||||
|
`--no-verify` flag.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
$ git commit --no-verify
|
||||||
|
```
|
||||||
|
|
||||||
|
With this checkpoint in place, you can either plunge forward with the feature
|
||||||
|
or you can even go fix the pre-commit violations and combine them into
|
||||||
|
(`--amend`) that checkpoint commit.
|
||||||
|
|
||||||
|
Don't abuse this. You still want the overall work to conform to project
|
||||||
|
guidelines. Use the process that works best for you as you get there.
|
||||||
|
|
||||||
|
See `man git-commit` for more details.
|
||||||
Reference in New Issue
Block a user