Hey devs! 👋

If you've ever worked on a project with a large team, you know how quickly branches can pile up. After months of development, dozens (or even hundreds) of branches end up sitting around. With time, it becomes a challenge to know what’s active, what’s abandoned, and what’s still needed. That's where Repo Pruner comes in.

I've built Repo Pruner as a GitHub Action to help solve this very issue — keeping repos clean and manageable, even when teams grow and activity ramps up. It automatically detects branches that have been inactive for a configurable amount of time and summarizes them for the team to review. It’s designed to help big teams avoid the clutter that comes with inactive branches, especially when we all forget to clean up after ourselves (guilty as charged 🙋‍♂️).

The Problem

In any project where you have a lot of team members, you’re going to have a lot of branches. Some people are diligent about deleting their old branches after merges or feature work. But let's be honest — in the rush to get things done, old branches often get overlooked. They start piling up, and eventually, no one knows which branches are safe to delete and which might still be needed. This creates a lot of confusion and makes it harder for the whole team to find what they need.

How Repo Pruner Helps

Repo Pruner runs as a scheduled GitHub Action, and here's what it does:

• Scans branches to find those that have been inactive beyond a certain threshold.
• Ignores protected branches (so nothing critical gets pruned).
• Creates a new summary issue listing all the branches that are candidates for deletion.
• Closes any previous summary issues to keep things fresh and organized.

This way, the team gets a new, updated overview of all the branches that have been inactive each time the workflow runs. The summary issue is easy to read and includes all the important details — branch name, last commit date, merged status, any associated pull request, and a chance for team members to mark each branch as Keep or Delete.

Why Close and Reopen Issues?

I wanted Repo Pruner to work in a way that doesn’t clutter up the issues page. Instead of endlessly updating one issue or spamming new issues every time it runs, Repo Pruner keeps it neat. It closes the previous issue and creates a fresh new one with up-to-date information. This way, every time you look at it, you’re seeing the latest status. And if anyone needs to look back at history, the old issues are still there, closed but preserved, so you can trace what’s been done.

How to Use It

It’s super simple to get started. Here’s how you can add Repo Pruner to your workflow:

name: "Run Repo Pruner"
on:
  schedule:
    - cron: '0 0 1 * *' # Runs once a month - At 00:00 on day-of-month 1.
  workflow_dispatch:

jobs:
  repo-pruner:
    runs-on: ubuntu-latest
    steps:
      - name: Run Repo Pruner
        uses: arminbro/repo-pruner@v2.1.17
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          inactive_days: 30

This workflow will run Repo Pruner every month and provide you with an overview of branches that have been inactive for more than 30 days.

Who Is It For?

If your repo only has a few branches, you might not need this. But if you’re working with a large team and multiple feature branches, stale branches can become a serious pain point. Repo Pruner is for teams that want to keep their repos tidy without spending hours manually checking branch activity. It’s perfect for big projects, especially those with frequent contributors who don’t always remember to clean up.

Final Thoughts

I’m all about making things easier for dev teams. Repo Pruner is one of those tools that makes the "housekeeping" part of development just a bit more manageable. Give it a try, and hopefully, it helps keep your repo a little more organized, too. If you use it or have suggestions for how it could be improved, feel free to drop me a line. Contributions and feedback are always welcome!

You can find Repo Pruner here: GitHub Marketplace Link

Happy pruning! 🌿

Armin

Would love to hear how you manage stale branches in your teams. Drop your thoughts in the comments below!