1. Gitleaks: Preventing Secret Exposure

Gitleaks is a free, open-source command-line tool for detecting exposed secrets, such as API keys, passwords, and access tokens, in Git repositories. It works from a built-in collection of detection rules, primarily regular expressions that recognize known token formats. It also supports entropy analysis, which measures how random-looking a string is, and this helps it catch potential secrets that do not match any known pattern. Custom rules and allowlists can further reduce false positives.

Gitleaks can scan in three ways: it can scan a repository’s Git history, it can scan files and directories directly, and it can scan content piped into it through standard input. It runs locally and never needs to transmit repository contents to an external service, which makes it safe to use on sensitive source code.

One distinction matters above all: removing a secret from the latest version of a file does not remove it from Git history. Anyone who can read the repository can travel back and find it. Scanning the history is therefore essential, not optional.

And if a scan does find a real secret in history, deletion alone is not a fix. A secret that has reached a shared repository must be treated as leaked, because copies may already exist in clones, forks, or caches that no cleanup can reach. History can be rewritten with tools such as git filter-repo, and that is worth doing, but the step that actually protects you is different: revoke the old credential and issue a new one, at the source where it was created. Rotation is the real remedy; cleaning is only tidying up afterward.

The cheapest protection of all is that the secret never enters a file Git can see. Secret-bearing files belong in .gitignore, example files should hold fake values only, and real credentials should live in environment variables or a secrets manager — anywhere except inside the repository itself.

2. Git Hooks: Automating Security Checks

A Git hook is a script that Git automatically executes at a particular point in a workflow. A pre-commit hook runs immediately before Git creates a commit, which makes it the natural place to run Gitleaks: if the scan finds exposed credentials, the commit is blocked before the secret ever enters history.

By default, Git looks for hooks in each repository’s .git/hooks/ directory, but maintaining hooks separately for every repository is inconvenient. Git therefore provides a setting called core.hooksPath, which redirects Git to a centralized hooks directory. Setting it globally — for example, git config –global core.hooksPath “C:/Users/YourUser/git-hooks” — applies it to all repositories for the current user, so one security hook can be maintained once and reused across many projects.

Two limits of hooks deserve honesty. A hook can be bypassed with a single flag, git commit –no-verify, and a hooksPath setting lives on one person’s machine, so it protects none of a team’s other machines and follows no one to a new computer. Hooks are a first line of defense, not the whole wall. The second line sits on the platform itself: GitHub’s secret scanning and push protection watch the receiving side and can refuse a push that contains a secret, catching exactly the cases a local hook misses.

3. Understanding Which Git Commands Matter

Git commands fall broadly into two families. Porcelain commands are the user-facing commands designed for everyday work, such as git status, git log, git diff, and git commit. Plumbing commands are the lower-level commands that expose Git’s internal operations, such as git rev-parse. The name rev-parse stands for revision parsing: it resolves revision references and reports facts about the repository, such as its root directory or its current commit hash. It is useful for scripting, but it is not something I need to master at the start.

For practical purposes, I should focus on a small working set. For inspecting a repository’s state and changes, git status, git log, and git diff cover nearly everything. For configuration, git config –get reads a setting, while git config with –global or –local changes a user-wide or repository-specific setting. For recording work, git commit is the central act. And for security, one command stands beside them: gitleaks git, scanning the repository’s history for exposed secrets.

4. Maintaining Visibility into AI-Executed Commands

As AI agents increasingly execute terminal commands on my behalf, I need to maintain visibility and control over their activities. Every command an AI agent executes should be identifiable and traceable. At a minimum, the execution log should capture the agent or session identifier, the timestamp, the exact command that was executed, the working directory and target repository, and the execution result together with its exit code.

The objective is not to prevent AI from executing commands. It is to make its actions observable and auditable, so that I can understand what it did, identify unintended changes, and investigate problems when they occur.

The principle is simple: AI can execute the work, but I should never lose visibility into what it has done.