How to choose which GitHub projects belong on your resume

Most active developers have somewhere between twenty and a hundred repositories: real projects, coursework, abandoned experiments, forks, and one-off scripts. None of that needs to appear on a resume. What belongs there is a short, deliberately chosen subset, and choosing badly is one of the more common ways a strong GitHub history fails to translate into a strong resume.

Start by excluding, not selecting

It is easier to rule things out first than to pick winners from scratch. Remove from consideration:

• Forked repositories with no meaningful commits of your own on top of them
• Coursework or tutorial-following repositories where the structure was given to you
• Anything abandoned before it reached a working state
• Duplicate projects that demonstrate the same skill twice

What is left is your real candidate pool, usually far smaller than the full profile.

Then rank by what each one proves

For each remaining project, ask what it demonstrates that nothing else on the resume already covers. A second React CRUD app does not add information once you already have one. A project involving a database schema you designed, a performance problem you solved, or a technology relevant to the job you want, does.

Three or four projects that each prove something different will always outperform six that all prove the same thing.

Completeness matters more than ambition

A project does not need to be large to be resume-worthy. It needs to be finished enough that a stranger can understand what it does within a minute of opening the repository: a clear name, a README explaining the purpose and how to run it, and a commit history that shows real, incremental work rather than a single “initial commit” dump. An ambitious but half-built framework with no documentation is a weaker resume entry than a small, complete command-line tool that does exactly what it claims.

Recent activity is a soft signal, not a hard rule

A strong project from two years ago that you can still speak to in detail is more useful than an unfinished one from last month. That said, an entirely dormant profile is worth noticing: if every listed project stopped receiving commits over a year ago, it is worth either updating one of them or building something new before applying, since recruiters checking a GitHub profile do look at recency as one signal among several.

Open-source contributions count differently than personal projects

A meaningful pull request merged into a project you do not own, fixing a real bug or shipping a real feature, is often stronger evidence than another personal project, because it was reviewed and accepted by people with no reason to be generous. If you have contributions like this, they deserve their own line even if the change itself was small: name the project, describe what you changed, and link the merged pull request directly rather than just the repository.

Pin them, then list the same ones on your resume

Whatever you decide belongs on your resume should also be pinned on your GitHub profile itself. A recruiter who clicks through from the resume to the profile and finds different, weaker projects pinned there gets a worse impression than if they had never clicked at all. Keeping the pinned set and the resume set identical is a small detail that consistently gets missed.

Letting the shortlist happen automatically

Manually auditing dozens of repositories to find the handful worth listing is slow. resumefromgit.com reads a public GitHub profile and ranks repositories by real signals, documentation, activity, and community engagement among them, surfacing the strongest candidates instead of requiring a manual review of the entire history. From there, see how to write a strong entry for each chosen project and how to put GitHub on a resume more broadly.