Is your feature request related to a problem? Please describe.
Given that we can now integrate gitleaks with pre-commit hooks, I can see the situation where a secret could be found during the pre-commit hook routine. However, if that secret is not an actual secret and simply something that gets identified as a false positive. We should be able to mark that line to be ignored.

Given that the pre-commit prevents commiting code when the gitleaks hook finds a secret, we can easily fall into a situation where the developers would end up blocked from going forward. And might even disable pre-commit altogether to be able to continue working.

Describe the solution you'd like
As it is the case with other tools that can run on the pre-commit hooks like Hadolint (linting of Dockerfile) or Shellcheck (to verify best practices on shell scripts); you may add a comment right before the line that will tell the linters (or gitleaks) to ignore the following line.

eg.

# hadolint ignore=DL3002
USER root

# shellcheck disable=SC2116,SC2086
hash=$(echo ${hash})    # trim spaces

Both tools have their rules named with specific names so you can refer to these rules in the ignore statement. For gitleaks, it could be as plain as :

# gitleaks ignore-line
not_a_password=abcdefgh

# gitleaks ignore
not_a_password=abcdefgh

Describe alternatives you've considered
The idea of going back to the gitleaks config file and updating the config to ignore that type of non-secret false-positive is the way to go, but in an environment where we have a large number of developers and they might not know how to manage that config file (or we might not want them to update the file as it's set as a company-wide defaults); a quick and easy way would be to allow for an inline ignore and allow them to continue on their merry way.

Additional context
More information here:
https://github.com/hadolint/hadolint#inline-ignores
https://github.com/koalaman/shellcheck/wiki/Ignore

cc @zricethezav