It happens to almost everyone, eventually.

You stage your changes, type git commit -am "wip", push — and a few minutes later realize that id_rsa (or .env, or credentials.json) was sitting in the working directory the whole time. The file is now in the remote, in every clone, in every CI cache, and worst of all: in the git history, where a simple git rm won’t touch it.

This post walks through fixing exactly that scenario with BFG Repo-Cleaner — a tool purpose-built for ripping unwanted blobs out of git history.

gitlab-backup2s3: Encrypted GitLab Backups to S3, with Kubernetes Support

Source code: github.com/sgaunet/gitlab-backup2s3 Helm chart: github.com/sgaunet/helm-gitlab-backup2s3

In the previous article, I covered gitlab-backup, a CLI tool for exporting GitLab projects and groups as portable archives. It handles the export, the restore, and supports both local and S3 storage natively.

But for production backup workflows — especially in a Kubernetes environment — you often want more: scheduled execution, optional encryption at rest, and a container image that bundles everything together. That’s exactly what gitlab-backup2s3 brings to the table.

Stop Committing Secrets: A Practical Guide to Pre-Commit Secret Detection

You’ve done it. Or someone on your team has. A .env file slips into a commit, an AWS key ends up in a config file, a GitLab token gets hardcoded in a script “just for testing”. A few minutes later it’s in your git history — forever.

This post covers the current best practice for catching secrets before they ever touch your repository, without drowning your team in false positives.

Working across large repositories that mix multiple technologies is common in modern software teams. Keeping everyone aligned on the same tool versions, environment variables, and runtimes has always been a friction point — until I started using Mise (mise-en-place).

It has since replaced several tools on my machine (goodbye nvm, reduced Homebrew usage) and become my go-to for managing development environments, both locally and in CI.

When your Go project depends on an internal library living in a private GitLab repository, a plain go get will fail — GitLab doesn’t know who is asking, and Go doesn’t know the repository is private. Fortunately, a handful of configuration steps sorts everything out, both locally and in CI.