Does GitHub Count as a Portfolio?
Not on its own. A GitHub profile is a list of repositories a reviewer has to open and run. One field on one repository turns it into something they can click.
By Howard Davner
💡 Quick Answer Not on its own. A GitHub profile is a list of repositories, and a repository is code a reviewer has to read or run before it shows them anything. It counts as a portfolio once one repository points at something already running. Every repository has a Website field in its About panel. Fill it in with a live URL and the link you were already sending leads somewhere clickable.
You put github.com/yourname on your resume because that is what everyone told you to do. That does not mean your code is bad. It means the link hands the reader a list when they wanted something they could try.
What the reviewer is actually holding
A GitHub profile is a directory. To get from a directory to evidence, someone has to pick a repository out of names like ml-final, COMP3700-a2 and portfolio-v3, open it, read a README, decide whether the code does what the README claims, and usually clone it and install its dependencies to find out.
None of that is hard. All of it is slow, and a first pass through an application pile is not.
The repository does not fail on quality. It fails on latency: it asks the reviewer to do work before it produces any output, at the one moment nobody has time for it.
GitHub versus portfolio is the wrong split
The real split is between an artifact someone has to run and an artifact that is already running.
A repository is the first kind. A live URL is the second: they click, the thing does something, and the evidence arrives before they have decided whether to bother. That is the case for putting a deployed project on your resume, and it is a claim about timing rather than code quality.
GitHub can be either kind. Most students only ever use it as the first.
The field most students never fill in
Every GitHub repository has an About panel on its page, and inside it a Website field. Whatever URL you put there appears in that panel, so anyone who opens the repository sees the running version before they see the file list.
It costs one paste. The sequence:
- Pick the one repository closest to the roles you are applying for.
- Deploy it somewhere it will stay up.
- Paste the live URL into that repository's Website field.
- Pin the repository so it sits at the top of your profile.
Now the GitHub link you were already sending leads somewhere clickable. Your resume should still carry the live URL directly, because one less click is one less place to lose someone, but the profile stops being a dead end for anyone who lands on it anyway.
Where to point it
GitHub can host the site itself if the project is static. GitHub Pages publishes HTML, CSS and JavaScript files straight from a repository, and it does not run server-side code. On a free GitHub account it works from public repositories.
What GitHub Pages can and cannot serve:
- A site of HTML, CSS and browser JavaScript: yes.
- Anything that needs a running server process: no.
- Anything that needs a database: no.
- Anything holding an API key that must stay secret: no, and no browser-only host can do it either.
That last case catches people. A key pasted into front-end JavaScript is readable by anyone who opens the browser's network tab, whoever hosts it. If your project calls a paid API, it needs somewhere to run server-side code. Vercel's free Hobby plan is meant for personal, non-commercial projects. Render offers free web services that suspend after 15 minutes without traffic and take about a minute to wake. Hugging Face Spaces has a free CPU tier for models, and free Spaces go to sleep when unused. Check each one's current terms before you rely on it, because free tiers change.
A sleeping app matters for what you send. A reviewer who clicks a cold link and waits a minute may not wait. Open your own link before every application, and read what a deployed project has to get right in the first thirty seconds.
Two things that quietly undercut a public repo
The history is public too, including what you deleted. Making a repository public makes every commit in it public. A credential you committed on Tuesday and removed on Wednesday is still sitting in Tuesday's commit. If this has already happened, rotate the key with whoever issued it. Scrubbing the history afterwards is housekeeping, and it is not what protects you.
Provenance shows. A forked repository carries a "forked from" line at the top, and a repository created from a course template says so. Neither is disqualifying, and neither is hidden. Anyone who opens the repository sees where it came from before they see a line of your code, which is a reason to send the strongest thing you built yourself rather than the one with the most commits.
When a GitHub link is the right thing to send
After the first screen, mostly.
Technical interviewers can read code. Take-home reviewers read code. Teams that work in the open may ask for a repository, and on those teams a thin commit history is a real gap. What those readers share is that they have already decided you are worth some of their time.
So GitHub is not useless. It is mistimed. It answers "how do you write code", which is the second question anyone asks, and it is silent on the first one, which is whether you finish things. What employers look for in a CS portfolio is mostly evidence of the second question, and a repository is the natural place to show it once someone is actually looking.
Send the live URL to the screen. Send the repository to the interview.
If nothing you have is worth pointing anywhere
Then that is the real problem, and no amount of profile tidying touches it.
The fastest way out is not to improve an old coursework repository. It is to build one small thing aimed at the kind of role you are applying for, deploy it, and point the repository at it. A narrow tool is understood in seconds and a broad one often is not. These AI project ideas are grouped by the sort of role each one is meant to answer.
If you would rather not start from a blank page, Provieo turns a job description into a working AI project you build and deploy, finishing with a live URL a hiring manager can open. It is free to use, your first project build and deploy is free, and after that it is $39 once with no subscription.
The bottom line
GitHub is where your code lives. That is not the same as a portfolio, and the gap is not about how good the code is.
A portfolio is something already running when a stranger clicks it. Your repository can be one paste away from that.
Build something worth pointing at →
Want a starting point before you sign up? The free Job Description Matcher shows example project directions for a posting, no account needed. It draws on a fixed set of ideas, so treat it as a prompt for your own, not a spec.
Frequently Asked Questions
Does GitHub count as a portfolio?+
Not on its own. A GitHub profile is a directory of repositories, and a repository is code someone has to read or run before it shows them anything. A portfolio is something a stranger can open and use immediately. GitHub becomes portfolio-shaped when a repository points at a working URL, which you do by filling in the Website field in that repository's About panel.
Is a GitHub link enough for an internship application?+
It suits the interview better than the first screen. A technical interviewer may read your code and ask for the repository. The person making the first pass through the pile usually cannot run it and has little time to try. Send a live URL for the screen and keep the repository link for the conversation that follows.
How do I turn a GitHub repo into a portfolio project?+
Deploy it, then connect the two. Pick the repository closest to the roles you are applying for, host it somewhere it stays up, and paste the resulting URL into the Website field in the repository's About panel so the code and the running version point at each other. Then put the live URL, not the repository link, on your resume.
Can I host my project on GitHub itself?+
Yes, if it is static. GitHub Pages publishes HTML, CSS and JavaScript files from a repository and does not run server-side code. On a free GitHub account it works from public repositories. Anything that needs a server process, a database, or an API key that must stay secret needs a platform that runs code, such as Vercel, Render, or Hugging Face Spaces for a model.
Is it risky to make my repositories public?+
The code is rarely the risk. The history is. Making a repository public makes every past commit public, so a key you committed once and deleted in a later commit is still readable in the earlier one. Deleting the file does not remove it from history. If that has happened, rotate the credential with the provider that issued it. Rewriting history afterwards is cleanup, not the fix.
Put a working link in your next application.
Paste the job you're applying to. Provieo designs a project against that exact listing and walks you through deploying it, so what a recruiter clicks is the work itself, not a description of it.
Free to use, and your first deployed project is free. Or tailor your resume to the same posting.