Git - Hard

Signed Commits and Verifying Authorship

Git records an author name and email on every commit, but that field is just text - anyone can set git config user.email to whatever they want. Signed commits use GPG or SSH keys to cryptographically prove a commit really came from the person it claims to.

git config commit.gpgsign true
git commit -S -m "Fix auth bypass"    # -S signs this commit
git log --show-signature -1            # verify a signature

In regulated environments, or any codebase where "prove who actually wrote this security fix" matters, signature verification can be enforced via branch protection (GitHub/GitLab both support "require signed commits"). Without enforcement, signing is opt-in and inconsistent - which for audit purposes is close to not having it at all.

---

Handling Leaked Secrets

An API key or password committed to Git isn't just "in the latest version" - it's in every clone's history forever, findable by anyone with access, even after you delete it in a later commit. Deleting the file doesn't delete the history.

The real fix is rewriting history to remove the secret from every commit that ever contained it, using git-filter-repo (the modern, recommended tool - filter-branch is legacy and much slower/riskier):

git filter-repo --path secrets.env --invert-paths   # strip this file from all history

But rewriting history only fixes your copy - anyone else who already cloned still has the secret in their history, and it may be cached in CI logs, forks, or search-engine caches of a public repo. This is why the actual first response to a leaked secret is always rotate the credential immediately - assume it's compromised the moment it's pushed, regardless of how fast you clean history afterward. History rewriting is cleanup, not the fix.

---

CI/CD Integration Patterns

Continuous integration systems clone repositories constantly, and naive full clones get slow and expensive at scale.

git clone --depth 1 https://github.com/org/repo.git   # shallow clone: only latest commit

Shallow clones dramatically speed up CI checkouts for jobs that only need the current code, but tools that need history (like bisect, or blame-based tooling, or git describe) will fail or behave oddly against a shallow clone - fetching more history mid-job (git fetch --deepen) is possible but adds back the cost you were avoiding.

Semantic release tooling reads conventional commit messages (fix:, feat:, BREAKING CHANGE:) to automatically compute the next version number, generate a changelog, and tag a release - removing the manual, error-prone "what version is this" decision from the release process entirely, at the cost of requiring commit message discipline across the whole team.