How to Use GitHub to Showcase Your Coding Projects

To showcase projects on GitHub, do five things: pin your best six repositories, give each one a README that explains the project in under a minute, host a live demo where possible, keep the commit history readable, and add a short profile README that says who you are and what you are looking for. A reviewer spends a few minutes on your profile at most, so make the best work easy to find and the rest invisible or tidy.

What reviewers actually look at

Hiring managers and recruiters skim. They open your profile, look at the pinned repositories, open one or two, read the README, and maybe glance at the code. They do not count green squares. What they are checking is simple: does this person finish things, can they explain them, and is the code readable? Everything below serves those three questions.

Set up the profile

1. Username and photo. A name close to your real one is easiest to recognize on a resume. You can rename your account in Settings, but links to your profile page will break, so pick a good one early.
2. Bio and links. One line on what you build and what stack you use, plus your location or time zone and a link to a portfolio site or LinkedIn. Keep it factual: “Backend developer, Python and PostgreSQL, looking for junior roles” says more than “passionate coder”.
3. Pin repositories. You can pin up to six repositories and gists combined. Pin the projects you want a stranger to open first, not the most recent ones.
4. Profile README. Create a public repository with exactly the same name as your username, add a README.md, and GitHub shows it at the top of your profile. Keep it short: who you are, two or three projects with one-line descriptions and links, and how to contact you.

A profile README does not need badges, animated headers or stat widgets. Those add noise and none of them tell a reviewer anything about your code. A plain version works better:

# Jane Doe

Backend developer. I build APIs in Python and Go and care about tests and clear docs.

## Projects
- [recipe-api](https://github.com/janedoe/recipe-api): REST API with auth, pagination and tests
- [chess-engine](https://github.com/janedoe/chess-engine): a small chess engine in Rust
- [cli-notes](https://github.com/janedoe/cli-notes): command-line notes app, published on PyPI

Contact: jane@example.com

The names above are placeholders; only claim things you can show.

Choose which projects to show

Three to six finished projects beat thirty abandoned ones. Pick projects that differ from each other and that match the job you want:

• One project with a back end, a database and authentication, deployed somewhere a reviewer can click.
• One that solves a real problem for you or someone you know. These are the ones you can discuss in an interview with real detail.
• One that shows testing or tooling: a CLI, a library, a package with tests and continuous integration.
• Optionally, algorithm practice in a separate repository, clearly labeled, so it does not clutter your main projects.

Tutorial clones (the same to-do app and weather app everyone builds) are fine for learning but weak as portfolio pieces. If you built one, change it enough that it is yours: a different data source, a new feature, tests. For ideas, see 10 impressive coding projects for your portfolio, and for the bigger picture how to build a portfolio as a beginner.

Archive or delete repositories you would be embarrassed by, or make them private. You can archive a repository in its Settings, which keeps it read-only and clearly marked as inactive.

Write a README that gets read

The README is the front page of the project. Put the answer to “what is this and why should I care” in the first three lines, then show it working. A structure that works:

# Project name

One sentence: what it does and for whom.

![Screenshot or GIF of the app](docs/demo.gif)

**Live demo:** https://example.com/demo

## Features
- Three to five bullets, concrete ("search by ingredient", not "powerful search")

## Tech stack
Python 3.12, FastAPI, PostgreSQL, Docker

## Run it locally
    git clone https://github.com/you/project.git
    cd project
    docker compose up
Then open http://localhost:8000.

## Tests
    pytest

## What I'd improve
Honest list of known limits. Reviewers like this.

Three details make the difference. First, test your install steps on a clean machine or in a fresh clone; a README whose commands fail is worse than none. Second, include a screenshot or short GIF at the top, because many visitors will not run anything. Third, state a design decision or trade-off (“I used SQLite to keep setup to zero; it would move to Postgres for multiple users”). That one sentence shows judgment, which is what employers are hiring.

Host a live demo with GitHub Pages

For static sites (HTML, CSS, JavaScript, or a React or Vue app built to static files), GitHub Pages hosts the result for free from a repository. As of October 2026 it is available for public repositories on GitHub Free, and for private ones on paid plans; check GitHub’s Pages documentation for current limits.

1. Open the repository’s Settings, then Pages.
2. Choose to deploy from a branch (or from a GitHub Actions workflow if your app needs a build step) and save.
3. After a minute the site appears at https://yourusername.github.io/repository-name/. A repository named yourusername.github.io becomes your root site, which makes a handy portfolio page.

Pages serves only static files. For a project with a server or database, use a free or low-cost host for your language and link it from the README. If the demo sleeps on a free tier, say so in the README so visitors wait for the first load instead of assuming it is broken.

Keep the code and history readable

• Commit messages. “Add pagination to recipe list” is useful; “fix”, “update” and “asdf” are not. Small commits with clear messages show how you work.
• Do not commit secrets. API keys, passwords and .env files must never go in a public repository. Add them to .gitignore before the first commit. If you leaked one, revoke it immediately; deleting it from the latest commit does not remove it from history.
• Add a .gitignore so node_modules, virtual environments and build output stay out.
• Add a license (MIT is common) if you want others to be allowed to reuse the code.
• Add tests and a basic CI check. A GitHub Actions workflow that runs the tests on every push, plus a passing badge, shows you ship checked code.

Use issues, branches and pull requests on your own projects

Even solo, work the way a team does: open an issue for each task, make a branch, and merge through a pull request. A reviewer who opens the repository sees a project that was managed, not dumped. See how to use GitHub issues to manage project tasks and understanding pull requests if this is new.

Contribute to open source, starting small

An accepted pull request to someone else’s project proves you can read unfamiliar code, follow conventions and take feedback, which is most of a real job. Start small:

1. Pick a tool you already use. You will understand the problems it has.
2. Read CONTRIBUTING.md and the open issues. Labels like “good first issue” mark tasks that maintainers consider suitable for newcomers; sites such as goodfirstissue.dev collect them.
3. Begin with documentation fixes, a failing test, or a small bug. Comment on the issue first to say you are working on it.
4. Fork, branch, make a focused change, run the project’s tests, and open a pull request that explains what and why.
5. Respond to review comments promptly and politely. Merged or not, the discussion is part of your record.

Do not submit unrequested mass changes or pull requests you cannot explain. Maintainers notice, and it hurts more than it helps.

Common mistakes

• Dozens of unfinished repositories pinned or visible, with names like test2 and untitled.
• No README, or the default one generated by a framework.
• Forks that look like your work. A fork with no changes of your own says nothing; do not pin it unless you contributed.
• Code you cannot explain. If an AI tool or a tutorial wrote part of it, understand it before it goes on your profile, because interviewers ask about it.
• Chasing the contribution graph. Empty “commits” to fill squares do not impress anyone who reads commit history.
• No link from your resume. Put your profile URL on the resume; see how to include your GitHub profile in your resume.

A one-hour cleanup checklist

1. Pin your best three to six repositories.
2. Archive or privatize anything unfinished or embarrassing.
3. Write or fix the README on each pinned project: summary, screenshot, run steps.
4. Add a live demo link to each project that can have one.
5. Search every pinned repository for secrets and large files that should not be there.
6. Create the profile README with three project links and a contact line.
7. Add the profile URL to your resume and LinkedIn.

Employers also want evidence you can solve problems under constraints, which a portfolio alone does not show. If you are preparing for interviews as well, pair your projects with regular algorithm practice, for example on AlgoCademy, which gives step-by-step guidance on problems.