Portfolio
A strong repo is easy to review. A stranger should quickly see where the app starts, where the code lives, and whether the project can be run safely.
Start with the top-level view. If the root folder has random files, old drafts, and final-v2 names, clean it before you write a better README.
Keep the structure simple. Do not add folders just to look serious. Use names people understand.
0 of 6 lessons done · proved by a submitted project with a public repository
For a small web app, this is enough. Source code goes in src. Public files go in public. Notes can go in docs.
Before
my-project/
app.js
index.html
styles.css
logo-final-new.png
test123.js
readme draft.txt
After
my-project/
src/
app.js
components/
public/
logo.png
docs/
notes.md
README.md
package.jsonDo each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
git add src/app.js
git commit -m "move app logic into src folder"
git add public/logo.png README.md
git commit -m "add project logo and usage notes"
git add package.json
git commit -m "add scripts for local run and build"Most review-ready repos have README.md and .gitignore. If the project is meant for reuse, add a license too.
For Node projects, keep package.json clean. For Python, include requirements.txt or pyproject.toml. For frontend frameworks, keep config files in normal expected places, not hidden inside a dump folder.
A .gitignore stops local files from entering GitHub. Add it before you push secrets or heavy folders by mistake.
Example .gitignore for Node
node_modules/
.env
.DS_Store
dist/
coverage/Add a license only if you want others to reuse or build on your code. MIT is a common simple choice for open sharing.
If you use MIT, use the standard MIT text from a trusted source. Update the copyright line with your name and year.
LICENSE
Use a standard MIT text from a trusted source, then update the copyright line with your name and year.Say you built a UPI expense tracker. Move app code into src, keep screenshots in public or assets, and keep notes in docs. Add .gitignore so .env and node_modules stay out of GitHub.
Then commit in small steps: create src structure, add expense form validation, ignore local config and build output.
package.json example
{
"name": "upi-expense-tracker",
"version": "1.0.0",
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
}
}Do not push secrets. If your repo contains passwords, API keys, or private tokens, remove them immediately and rotate the keys.
Do not try to make the repo look big. Clean names beat too many folders, too many docs, and confusing names like final-v2-new-new.
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Answer the quick check to finish this lesson.