Open your own GitHub profile. Scroll down to the contribution graph — a string of light-colored squares stretching for weeks, then suddenly clustering dark right three days before the deadline. Click on your newest repo: no README, or README with just the default # my-project line. Check the commit history: fix bug, fix bug 2, asdasd, final_v3_that_su_la_final.

If you just flinched because that sounds exactly like your repo, don’t worry — almost everyone who’s learned to code has been through this phase. The problem is recruiters skim a repo for a few seconds before deciding whether to read further, and a repo like the one above gets skipped almost immediately.

Quick clarification so nobody gets confused before the main part: Git is a version control tool that runs right on your machine, usable even offline. GitHub is where you save that copy to the cloud, plus a bunch of collaboration features — Pull Requests, Issues, Actions, Secret Scanning. You can absolutely use Git without GitHub, but GitHub really shines when you need team collaboration or a backup location.

That’s the mandatory theory out of the way. Now for the 5 specific mistakes that almost every newbie makes — and how to fix each one in under 5 minutes.

1. Treating a Repo as a Secondary Hard Drive, Not a Capability Portfolio

No README.md means viewers don’t know what the project does, what technologies it uses, or what commands to run to try it. Most will close the tab before reading the first line of code.

How to fix: a minimal README only needs four parts — project name with a one-sentence description, a demo image or gif if there’s a UI, installation and run instructions, and a list of technologies used. It doesn’t need to be long, just enough for a stranger to understand in half a minute.

2. Not Using .gitignore — Turning the Repo Into a Junkyard, or Worse, Leaking Passwords

This is the most dangerous mistake in the list. Not creating .gitignore from the start means node_modules/ or .env files can easily get swept up by git add . without anyone noticing. node_modules/ just makes the repo heavy and ugly. But .env files containing API keys or database passwords are a completely different story.

GitHub has Secret Scanning that automatically scans Public Repos to detect common secret key formats. But that’s not the only shield needed — out there exists an entire ecosystem of bots run by bad actors silently monitoring GitHub’s public event streams in near real-time, just to “harvest” keys the moment they appear. More than a few developers have shared stories of receiving emails warning that their AWS costs had skyrocketed within minutes of accidentally pushing a .env file.

How to fix:

  • Create .gitignore before the first git add ., not after you’ve already committed.
  • If creating a new repo directly on GitHub.com, you can select a pre-made .gitignore template based on your language (Node, Python, Java…) right in the setup step, no need to type it from scratch.
  • Use a .env.example file containing only variable names, not actual values, so others know what to declare.
  • If you’ve already accidentally pushed a real secret: deleting the file in a later commit isn’t enough, because the old value is still in Git history. The first thing to do is revoke that key at the issuer, then worry about cleaning up history.

3. Writing Commit Messages Like Personal Inner Monologue

fix bug, fix bug 2, asdasd, update — the commit history is the story of the entire project. Code reviewers, or yourself six months later, will rely on it to understand why a code section changed, instead of having to read the entire diff.

How to fix: use the concise Conventional Commits format — a prefix describing the type of change, followed by a description in present tense:

feat: add user login with JWT
fix: resolve null pointer when checkout
docs: update installation guide in README
refactor: extract validate logic to separate function

Just getting comfortable with four prefixes — feat, fix, docs, refactor — is enough for most personal projects.

4. Coding Directly on the Main Branch — and the Nightmare Called “Conflict”

A familiar situation for anyone who’s done group assignments: three people edit app.js directly on main at the same time. The second person pushes, the third pulls and immediately sees CONFLICT (content): Merge conflict in app.js, nobody’s sure whether their code or the other’s is the correct version, the whole group spends the night before the deadline manually resolving conflicts.

How to fix: each person, or each feature, works on their own branch, only merging into main via Pull Request after review:

git checkout -b feature/login
# ... implement login feature ...
git add .
git commit -m "feat: add login form"
git push -u origin feature/login

Then open a Pull Request on GitHub for others to review before merging. Conflicts can still happen, but only within a controlled, reviewed scope, instead of exploding directly on main.

5. Saving an Entire Semester’s Work for One Single Commit

The contribution graph is what many recruiters glance at first. A string of evenly distributed squares over many weeks speaks to good work habits far better than a single dark cluster appearing the night before deadline.

How to fix: commit as soon as a small part works, don’t wait until “everything is done”. One small, complete feature should be one commit — no need to wait until the entire project is finished before pushing.

Hands-On: Build a Clean Repo From Scratch

Instead of creating a repo and only then realizing what’s missing, here’s the order to do it from the very first commit:

# 1. Initialize Git in the project directory
git init

# 2. Create README right away, don't leave it blank
echo "# My First Project" > README.md

# 3. Create .gitignore BEFORE adding any files
echo "node_modules/" > .gitignore
echo ".env" >> .gitignore

# 4. Add and commit
git add .
git commit -m "feat: initial project setup"

# 5. Rename default branch to main
git branch -M main

# 6. Link to the repo created on GitHub
git remote add origin https://github.com/username/repo.git

# 7. Push code up
git push -u origin main

The order in steps 2 and 3 is more important than it seems: .gitignore must exist before the first git add .. Once a file has been committed, adding it to .gitignore later won’t automatically remove it from history — you need to run git rm --cached <filename> to untrack it.

3 Golden Rules for GitHub to Truly Be a Portfolio, Not a Temporary Storage

  1. Always have .gitignore from the very first commit, and never commit files containing real secrets.
  2. A proper README.md — project description, demo image or gif, run instructions, technologies used.
  3. Commit regularly with clear messages — many small, meaningful commits are always better than one giant commit at the last minute.

The next thing to do isn’t reading more theory — it’s opening your most recent repo right now, checking which of the 5 mistakes above it has, then fixing them with the exact command blocks above.

Sources: