4 ms·
I (think i) understand it, but i did not understand the workflow. Before i commit, i run local tests to be sure that my code is ok (with jshint, ...). Normally
by progx 12y ago
I (think i) understand it, but i did not understand the workflow.
Before i commit, i run local tests to be sure that my code is ok (with jshint, ...).
Normally i work with my local branch before i push it to other developers.
Why should i share unfinished untested code to others?
Or is pre-commit a kind of local history (like Eclipse holds it in background for every file)?
- michaelmior 12y agoYou don't have to share any of the code. The idea is that before committing, you run the tests that you mention and you're blocked from committing if those tests don't pass. That's really all there is to it. You can disable those checks at any point when you commit if you wish.
- ethomson 12y agoNo, there is no change in how you share, nor is this any sort of local history. Git has the concept of "pre-commit hooks" which is a script that is run (by git itself) whenever you run "git commit", before your changes actually land in the repository. This can be used to (for example) run your local tests for you, as a sanity check. However, your hooks are configured on a per-repository basis, and not transferred when you clone. So you would need to configure these manually each time you clone. It's easy to forget to set up the hook with all the things you need to run. This tool is to help alleviate some of the pain in this, by having a configuration file to set up all the necessary hooks, as well as having a library of default hooks (whitespace checks, etc).