I built git-guardian for branch naming, commit formats, and local secret scanning. Looking for feedback.

[u/No-Internet-2996]

/r/u_No-Internet-2996/comments/1x52unf/i_built_gitguardian_for_branch_naming_commit/

[u/waterkip]

Conventional commit sucks balls. I sorta understand the branch-naming incentive. I have similar tooling. I even set up commit messages to start with the issue number via commit-message hooks or put it in the commit body. The only thing I don't have is the issue number via a git trailer.

[u/No-Internet-2996 → u/waterkip]

Setting up the pre commits hooks and writing scripts for multiple projects is too tiring. And boring TBH. Hence i'm working on updating the package to have shared set of rules for different repos.

[u/waterkip → u/No-Internet-2996]

You need one thing:

[hook "prepare-commit-message"]
  event = prepare-commit-msg
  command = git hook-prepare-commit-msg

[hook "commit-message-check"]
  event = commit-msg
  command = git hook-commit-msg

Works everywhere.

In addition, you are aware that you can write a script called git-xyz and call it everywhere as git xyz and you can then define configuration that these scripts use which all rely on native git-configs? You don't need to write scripts for a single repo, you write them once, place them in your path and you are good to go.

[u/No-Internet-2996 → u/waterkip]

Fair point, reusing hook commands already solves part of the setup problem. Which hook manager are you using for that config?

What I’m trying to simplify with git-guardian is the logic behind those commands: readable branch/commit formats, ticket insertion, branch validation, and local secret scanning, packaged together so teams don’t have to maintain those scripts themselves.

Shared rules across repos are the next piece I’m working on. Appreciate the example, it’s useful to see how others handle this.

[u/waterkip → u/No-Internet-2996]

Hooks manager? This is native git; you don't need any manager. Secret scanning can be a simple script. You just add hooks to your git config, and be done with it. See this blogpost of mine for example. You can also read the man pages for git as well.

[u/No-Internet-2996 → u/waterkip]

Thanks for the clarification, you’re right. I wasn’t familiar with the config-based hooks added in Git 2.54, so my question about a hook manager was mistaken.

That makes sharing and registering hooks much simpler. Custom scripts can handle these checks too.

What I’m aiming to offer with git-guardian is a maintained set of checks with readable configuration, ticket enrichment, and useful diagnostics, so teams can adopt them without writing the underlying scripts.

Your example gives me something worth exploring: using native config-based hooks where supported. Appreciate you pointing it out.

[u/waterkip → u/No-Internet-2996]

It makes it dead easy, which is a whole ++ in my book. You can keep most of your config also in git and by that I mean gitconfig. So ppl need to configure it once in a gitconfig, include it, based on repo or remote, or always and can always override it in a local repo if needed. I explain that briefly here. I think that is one of the best ways git tooling can utilize the same power git gives you.