DEV Community: RepoSweeper

Before You Leave GitHub, You Need to Know What's Actually There

RepoSweeper — Tue, 14 Apr 2026 14:28:56 +0000

I love GitHub, but it's changing.
Somewhere along the road GitHub stopped feeling like a developer tool and started feeling like a Microsoft product. The Copilot push left a sour taste in my mouth. The stalled feature requests. Years-old issues sitting untouched while competitors ship. Newer git providers like Codeberg, Forgejo and Gitea aren't having these problems. They are building what GitHub stopped bothering to. They're faster, they care about privacy in ways Microsoft doesn't, and they're run by people who actually use them. Nobody's saying GitHub is going away, but for the first time in mainstream dev culture it feels like serious developers are starting to ask 'how do I offramp?'.

GitHub has years of your work. Do you know what's there?
Depending on when you made your account, you might have a decade of work sitting on Github. Some of it's public. Some of it should definitely not be. A few private repos probably have collaborators you added years ago and completely forgot about. GitHub became the default so gradually that most developers never bothered to take stock of what accumulated. And now the platform holds something closer to a fingerprint of your professional life than a storage bucket. Leaving means losing your star history, your fork graph, your contributor graph, that is the social proof that took years to build. So before you rage-migrate to a self-hosted Gitea instance at 2am because you read one too many HN threads, do this first.

Step 1: Audit what you actually have
Go to your profile. Not the pinned repos…. all of them. Scroll to the bottom. Most developers with a few years of experience have somewhere between 30 and 60 repos and haven't thought about half of them since they were created. A third are genuinely active. The rest are tutorials they cloned once, side projects that got three commits, forks they made to submit a PR and never cleaned up. If you're thinking about migrating, you also don't want to drag all of that with you. Moving 50 repos to a new host is only worth it for the handful that actually matter.

Step 2: Clean house before you decide
Once you can see everything, the decision gets a lot clearer. The repos worth moving are probably 5–10% of what's there. Archive what you want to keep with RepoSweeper. Delete the genuine junk. Make private anything that was accidentally public. Remove collaborators you don't recognize anymore.
This is something worth doing every year regardless of where you host. Your GitHub profile is still the first place a hiring manager or potential collaborator looks. Eight active, well-documented projects reads completely differently than a graveyard of 60 repos where the most recent commit was two years ago.

Step 3: Then decide where you actually want to go
A few options worth taking seriously:
Codeberg - Non-profit, EU-based, runs Forgejo. The privacy story is about as clean as you'll find anywhere. Good for open source work where signaling values matters to you. The community is smaller, so discoverability takes a hit.
Forgejo - The open source fork of Gitea, maintained by the community after the governance dispute. Self-hostable or use a provider. Full control, no drama.
GitLab - The most GitHub-like experience. Better CI/CD story, strong privacy options, self-hostable. Still a company with its own incentives, but a different risk profile than Microsoft.
Self-hosted Gitea - Maximum control, maximum maintenance burden. Worth it if you already have the infrastructure. Probably not worth it if you're a solo developer who just wants to ship things without becoming a sysadmin.
Honestly, the hedged approach makes sense for most people: keep a GitHub presence for discoverability - it's still where open source contributors and hiring managers look - and run your active private work wherever you actually trust.

The one habit that makes this sustainable
The real problem isn't which provider you use; it's that most developers have no visibility into their own activity across repos. You push code, context-switch, push more code. It's too easy to lose track of what you've shipped. RepoRecap sends you a weekly AI summary of your own commits: what you built, what themes emerged, what you actually accomplished. It works off your GitHub activity today and will work wherever you end up. It's the easiest way to track your productivity across all of your repositories. If you're anxious about GitHub's direction, that's a reasonable feeling. Your first move should be knowing what you have, cleaning it up, and building habits that make you less dependent on any single platform.

- -
RepoSweeper is free - see everything you have on GitHub in one view. RepoRecap sends you a weekly digest of your own activity. Both are at reposweeper.com.

I'm never prepping for standup again

RepoSweeper — Tue, 24 Mar 2026 21:52:03 +0000

I'm so done prepping for standups that I built something to do it for me.

I was tired of being punished for being productive in the form of shipping features all week across multiple repos, then blanking when someone asks what I actually did.

My shipping cycle went bananas after using Claude CLI. So instead of slowing down my work ethic to fit standup cadence, I wired it into the GitHub API and added it to RepoSweeper.

Here's what this week's digest looked like with zero effort on my part:

It breaks down work themes as well in order to cover both the technical impact and the business impacts.

It also includes Highlights and a Repo activity breakdown.

The point is: I didn't write any of that. I just committed code all week and this arrived in my inbox!

I Found a 2-Year-Old GitHub Feature Request and Built It

RepoSweeper — Sat, 07 Mar 2026 17:16:06 +0000

A few weeks ago I was browsing GitHub Discussions and found a thread from September 2023. A developer named Nathan had posted asking for a proper branch cleanup tool — filter by last commit age, see who touched what, bulk delete stale branches.

It had been sitting open for two years. The best official response was essentially "have you tried the Stale tab?" which still makes you click delete one branch at a time.

The scope of the problem

The Stack Overflow question "How do I remove all stale branches from GitHub?" has 40,000 views. The workaround most people land on looks like this:

git push origin --delete branch-name-1
git push origin --delete branch-name-2
# repeat 40 more times

Or you write a script against the GitHub API, handle auth, pagination, and hope you don't accidentally nuke something active.

So I built built a modern version

I already had reposweeper.com — a free tool for bulk repo management (archive, delete, visibility, collaborators) which I built to address a similar GitHub limitation. Adding branch management felt like the obvious next step.

You open a repo, every branch is sorted by last commit date with the author and commit message right there, you select the ones you want gone, and delete them in one shot. Protected branches are flagged so you can't accidentally select them.

It's four steps:

Select the repo you want to clean up
Hit Manage Branches
Select the stale branches
Hit Delete

reposweeper.com

I also went back and replied to Nathan's original thread with the link. Two years is a long time to wait for a feature.

If you have suggestions or run into anything weird, drop a comment.

I launched on 3 platforms with 0 followers. My 7-year-old article beat all of them.

RepoSweeper — Sun, 22 Feb 2026 22:25:06 +0000

Three days ago I launched a major update to RepoSweeper — a tool for bulk managing GitHub repos (delete, archive, change visibility, AI commit summaries, etc.).

Here's everything I did to promote it:

Published a new Medium article
Posted on our LinkedIn company page (0 followers)
Posted here on dev.to (0 followers — hi 👋)
Updated a 2018 article about the original version of the app, adding a paragraph pointing to the new one

Here's what actually happened to traffic (Cloudflare, unique visitors):

Date	Unique Visitors
Feb 8–17 avg	~220/day
Feb 18	451
Feb 19	589
Feb 20	336
Feb 21	327

Nearly 3x baseline on day 2. Signups went from ~1/day to 3–4/day.

So what drove it?

Not LinkedIn. Not dev.to. Not the new Medium article — it has 20 reads.

It was a 2018 article: "The Easiest Way To Delete Multiple GitHub Repositories At Once" — a simple how-to I wrote right after bootcamp when I first built the app. It has 25K reads accumulated over 7 years, mostly from Google.

Before I updated it: ~2 reads/day (basically dead)
After adding a single paragraph at the top linking to the new version: 9 → 16 → 12 reads/day

Those readers are hitting the site.

The lesson

If you've been writing about your work for years, you have assets you've forgotten about. Old tutorials. Old how-tos. Old "I built this" posts. They're sitting on Google's index, quietly collecting readers.

Updating one takes 10 minutes. Building a new audience from zero takes months.

I'm not saying don't post new content. I'm saying: before you grind to build a new following from scratch, go check what you already have.

What's the oldest thing you've published that's still getting traffic?

Do you think there's value in automated git summaries for standups and sprint reviews?

RepoSweeper — Sat, 21 Feb 2026 19:34:00 +0000

I built a small tool and I'm honestly at a loss trying to figure out if it's solving a real problem or not. It let's you generate plain-English summaries (both technical and business impact) of what you actually worked on in a connected repo over whatever time period you select. I built it because I realized with llm's I was dev'ing a lot faster than the ticket cadence by my PM and was losing track of how much I actually built.

So I use it for standups, but I could see it being useful for quarterly reviews, investor meetings, or even as a daily digest.

The Confusion
I talked to a PM friend today who basically said "interesting but I wouldn't pay for it — I already get this from Linear." My pushback was that Linear already uses tickets as the source of truth. And it doesn't actually take into account what happened. Anyway, he's probably right for his situation. But I'm not sure PM's at a very modern startup is my MCP. So I'm asking here instead bc I'm more interested in what independent devs think.

Some Questions

Do you ever struggle to summarize what you worked on — for standups, PRs, performance reviews, billing clients, or just your own tracking? Or is this a non-problem for you?
If the tool emailed you a summary every Friday automatically (or every sprint, or daily — your choice) without you having to open anything, would that be worth anything to you? Like, would you pay $5/month for that?
Is there a different version of this that would actually be useful to you? I'm not attached to the current form.

Happy to share the site in the comments if anyone's interested or needs more context to answer.

Thank you so much in advance,

I wrote a dev tool post that got 25k reads. My follow-up got 11. Here's what I learned.

RepoSweeper — Fri, 20 Feb 2026 23:30:35 +0000

Back in 2018 I wrote a Medium article about a school project I built to help clean up GitHub repositories. I had published the little app and shared it with classmates. Little did I know that people were using the tool!

The way I found out was this: I published some other crappy article on Medium and wanted to see how many people had read it. It was something like 6. But I couldn't help but notice there were over 10k reads on the dev tool one. And a bunch of comments about how it's broken and it sucks. Woo hoo.

So I immediately fixed all the bugs and responded to the comments.
After that I polished up the app, made a new UI, and generally got obsessed with the the project again.

Funnily enough, even after that wake up call I didn't think about starting a db to track usage. I eventually did in 2022, but I lost 4 years of it's most popular time period. The db went down in 2024 and I didn't notice for like 9 months. Jeez. There were a lot of hard lessons learned here.

Eventually I got all the basics covered. But at that point the need for the tool died down significantly. I've tracked that we've had 6.5k unique signups for the RepoSweeper between 2022-2024 + 2025-2026. In reality the number is prob north of 15k.

Not many people squander lightning in a bottle as regularly as I do.

I recently expanded the tool suite to do other bulk actions that I saw in Github's Community Discussion board: collaborator management, visibility setting, archives, etc.

Anyway. I did a writeup about the new features and documented everything I'd built.

11 reads.

Not 11k. Eleven.

The painful irony is that the product is genuinely more useful now. But "more useful" doesn't make for a better headline.

The original post worked because it was about the reader's problem, not my product. "25 ways my tool helps you" is always worse than "here's the exact shell command I was too lazy to remember."

Every good dev post probably has one job: make the reader feel seen before you make them feel sold to.

I built something that solved a real problem for me, wrote honestly about it, and 25k people related. Then I got excited about what I built next, wrote about that, and almost nobody cared — because I switched from their perspective to mine.

Going back to basics. Next post: one problem, one solution, one story.
Hopefully I'll notice when it blows up this time.
RepoSweeper is still free if you want to check it out. RepoRecap PRO is the AI layer I got too excited about. Roast me in the comments.

Roast me in the comments.

GitHub Has No Bulk Anything. So I Built It.

RepoSweeper — Thu, 19 Feb 2026 14:25:00 +0000

In 2018, I built a single-purpose tool: bulk delete GitHub repositories.

It was originally just for myself and my classmates: Select repos, click delete, confirm. The whole thing was maybe 200 lines of code.

I wrote a Medium article about it that got 25,000 views and the tool gained over 6,500 developers, most of them in the last four years without me touching the product.

Even though it was nice having people use my tool, I never really gave much thought into expanding it until recently. I did a quick analysis of common requests on GitHub’s Discussion board, and there are many in the category of bulk management.

—

What I Found in the Forum Threads

I always thought of participation as binary: a user either uses your tool or they don’t. So I never tried to understand what my users actually wanted. But then I found something revealing.

The single most telling thread was this one: “Create groups of repositories” — 500+ reactions, 150+ comments, and a comment that stopped me cold:

“People have been asking for this for more than a decade. GitHub doesn’t seem to care or have any desire to offer it.”

There were many of these multi-year accumulations of developers who had simply given up expecting GitHub to fix their problems. Many going back multiple years.

The themes that kept appearing across threads

Group creation and tagging. Organize repos by group (work, personal, school) — and take actions on the whole group at once.
Visibility control: Moving repos between public and private.
Repository staleness: A way to sort by “what hasn’t been touched in 3 years” or “actively maintained.”

—Collaborator cleanup: A way to add/remove collaborators across repos after a project ends, someone leaves a company, or a team gets reorganized.

So I Expanded RepoSweeper

RepoSweeper in 2026 is not the tool I built in 2018. It’s a full GitHub repository management toolkit.

I took all the scattered, unanswered requests by Github and built them into RepoSweeper’s dashboard.

Bulk archive.
Bulk privacy management
Collaborator cleanup (add/remove)
Staleness scoring and sorting (act on the least used repos first)

Combined, the dashboard is now closer to a management console than a deletion tool.

Try It

RepoSweeper— free forever:
Sign in with GitHub. No install. Start managing your repos in 60 seconds.

—
What’s your biggest GitHub management headache? I read every comment.
—

If you use RepoSweeper, I’m actively reading every piece of feedback. Reply to this article, email reposweeper@gmail.com, or just describe your problem — this product has always been shaped by the people who use it.