Dispatches¶

Managing Stale Issues and Pull Requests with GitHub Actions

Every open-source project eventually faces the same problem: issues and pull requests that were once active go quiet. A bug report with no updates in a year. A pull request that was never finished. A feature request that the contributor lost interest in. These threads accumulate over time, and before long a repository's issue tracker becomes a graveyard of items that no one knows are still relevant.

The actions/stale GitHub Action gives maintainers a way to address this automatically. It scans issues and pull requests on a schedule, labels anything that has gone too long without activity, warns contributors that it will be closed soon, and closes it if no activity follows. The whole process is configurable and runs without manual intervention.

This post covers what the action does, how to configure it, a real-world example from one of my own projects, and an honest look at the tradeoffs so you can decide whether it makes sense for yours.

Ignoring Files in Git with .gitignore

Every Git repository accumulates files that should never be committed: compiled binaries, dependency directories, editor configuration, operating system metadata, and local environment files that contain secrets. Without a mechanism to exclude them, every git status output and git add . command becomes a manual filtering exercise. The .gitignore file is Git's built-in solution to that problem, and understanding how it works end to end, including its pattern syntax, scope model, and debugging tools, eliminates a class of frustration that affects developers at every experience level.

Tracking Empty Directories in Git with .gitkeep

Git tracks files, not directories. That distinction is easy to overlook until you run into the consequence: an empty directory you create locally simply does not exist after a fresh clone. No staging, no commit, no push will capture it, because Git has nothing to work with. The .gitkeep convention is the widely adopted workaround for this behavior, and it requires nothing more than a single empty file placed inside the directory you need to preserve.

Controlling Git Repository Behavior with .gitattributes

A .gitattributes file lets you assign attributes to file paths in a Git repository, giving you explicit control over how Git handles those files during checkouts, merges, diffs, and archives. Line ending inconsistencies, corrupted binary diffs, merge conflicts in generated files, and bloated archive packages are all problems that a well-constructed .gitattributes file prevents before they reach your team.

Managing GitHub Repository Settings with Probot Settings

GitHub repository settings can be managed through the web UI, the REST API, or the gh CLI. Default branch, merge strategies, issue tracking, vulnerability alerts, labels, branch protection rules: regardless of how you change them, the result is the same: no audit trail tied to your repository, no peer review process, and no straightforward way to reproduce the configuration in another repository without repeating the same steps manually.

The Probot Settings app solves that problem by treating repository configuration as code. You commit a .github/settings.yml file to your repository, and the app syncs its contents to GitHub's API every time the file changes. The settings are versioned, reviewable, and repeatable.

This post covers how the app works, how to install it, what it can configure, and how to structure a settings.yml file that covers the settings I apply to every project.