Suggestion - Documentation & new option around commit hook

[stuartjnelson]

• Version: 10.0.1
• Node: v18.18.2

We're using this plugin which is awesome. Recently we got an error when running semantic-release in our pipeline that took us a while to figure out.

[semantic-release] › ✘  Failed step "prepare" of plugin "@semantic-release/git"
[semantic-release] › ✘  An error occurred while running semantic-release: Error: Command failed with exit code 1: git commit -m chore(release): <version number> [skip ci]

We are using Husky, but that's disabled in the pipeline. There was a log at the bottom regarding our unit tests which I thought was a result of the job failing. This was an incorrect assumption. It was because our unit tests were being run due to the plugin and there was missing a build file. I was unaware until I looked at the source code that this plugin would run our git commit hook (which now feels obvious). Before putting in a PR I wanted to open a ticket with my suggestions;

1. Update README.md so its clear if you have a git commit hook it will be ran
2. Provide an option to add the --no-verify flag to the commit function
3. Add some logging for when a commit hook runs, finishes and if it fails

I'm unsure how to do the 3rd option but something like the below I feel would work.

async function commit(message, execaOptions, noVerify = false) {
  const gitArgs = ['commit', '-m', message];

  // Add --no-verify flag if noVerify is true
  if (noVerify) {
    gitArgs.push('--no-verify');
  }

  try {
    console.log('Running git commit');
    await execa('git', gitArgs, execaOptions);
    console.log('Commit successful.');
  } catch (error) {
    console.error('Error during git commit:', error);
    throw error; // Rethrow the error to handle it outside this function if needed
  }
}

[travi]

We are using Husky, but that's disabled in the pipeline

Clearly, it isn't actually disabled. Husky does provide configuration to disable it properly:

#505 (comment)

We won't be adding extra configuration options to handle this situation, but would accept PRs to update our docs and point to those husky details