The GitHub Mistakes I Made as a Fresher
When I started using GitHub as a fresher, I thought I was doing things right.
I had repositories.
I pushed code.
My profile wasn’t empty.
But looking back now, I realise I was using GitHub — not understanding it.
Most of my mistakes didn’t break anything immediately.
They slowed my growth silently.
This post is about the GitHub mistakes I made as a fresher, and what I learned from them.
Mistake #1: Treating GitHub Like Google Drive
Initially, GitHub was just a place to dump code for me.
- Upload project
- Push once
- Never touch it again
I didn’t:
- Track changes properly
- Use commits meaningfully
- Improve projects over time
Later, I understood GitHub is not storage.
It’s history.
Once I started committing regularly and improving the same project, learning became much deeper.
(This mindset shift is similar to why GitHub became important for me →
https://dailydevnotes.in/importance-of-github-for-software-engineers)
Mistake #2: Bad (or No) Commit Messages
My early commit messages looked like this:
finalupdatefixchanges
They meant nothing.
Now I realise:
A commit message is a conversation with your future self and your team.
Good commits explain:
- What changed
- Why it changed
- What problem it solves
Clear commit messages made debugging and collaboration much easier later.
Mistake #3: Too Many Repositories, Too Little Depth
As a fresher, I thought more repos = more skill.
So I had:
- 10–15 half-done projects
- Similar clones
- No clear purpose
What I learned later:
One evolving project teaches more than ten unfinished ones.
Now I focus on:
- Fewer projects
- Better structure
- Incremental improvements
- Clear READMEs
Quality beats quantity — especially on GitHub.
Mistake #4: No README (Or a Very Poor One)
Earlier, my README was either missing or had:
- Project name
- “Made using XYZ”
- Nothing else
That’s not enough.
A README should answer:
- What problem does this solve?
- How does it work?
- How to run it?
- What did I learn building this?
Writing READMEs forced me to understand my own project better.
Mistake #5: Never Revisiting Old Code
Once a project was “done”, I moved on.
I never:
- Refactored it
- Improved structure
- Fixed edge cases
- Added features
Later, when I revisited old code, I realised how much I had improved — and how much I missed by not revisiting.
Growth becomes visible only when you compare past and present code.
Mistake #6: Copy–Pasting Without Understanding
I copied a lot of code from:
- StackOverflow
- GitHub repos
- Blogs
Copying itself wasn’t wrong.
Copying without understanding was.
Whenever copied code broke, I was stuck.
Now, I:
- Rewrite copied code
- Understand each line
- Test it independently
This habit also made debugging easier
(which I wrote about here →
https://dailydevnotes.in/how-i-debug-when-i-dont-know-where-the-bug-is)
Mistake #7: Ignoring GitHub Issues and Pull Requests
As a fresher working solo, I thought:
“Issues and PRs are for big teams.”
That was wrong.
Using issues helped me:
- Break work into tasks
- Track bugs
- Think in features
Using PRs (even alone) helped me:
- Review my own code
- Understand change impact
- Write better descriptions
This prepared me naturally for team environments later.
Mistake #8: Chasing Stars Instead of Skills
At some point, I started caring about:
- Stars
- Forks
- Profile looks
But GitHub rewards consistency, not virality.
Most recruiters and seniors don’t care about stars.
They care about:
- How you think
- How you structure code
- How you explain decisions
That changed my focus completely.
What I Do Differently Now
Today, I treat GitHub as:
- A learning log
- A growth timeline
- A reflection tool
I focus on:
- Clear commits
- Fewer, better projects
- Regular updates
- Honest READMEs
This habit carried over directly into professional work and startups
(which shaped my early career →
https://dailydevnotes.in/one-year-startup-software-engineer-lessons)
If You’re a Fresher, Remember This
You don’t need:
- Fancy projects
- Viral repositories
- Perfect code
You need:
- Consistency
- Curiosity
- Ownership
- Reflection
GitHub will amplify whatever habit you bring to it.
External Resources That Actually Help
These helped me understand GitHub better over time:
- GitHub Docs – Getting Started
https://docs.github.com/en/get-started - Conventional Commits Guide
https://www.conventionalcommits.org/ - How to Write a Good README
https://www.makeareadme.com/
Use them as references, not checklists.
Final Thoughts
GitHub didn’t expose my mistakes to embarrass me.
It exposed them so I could grow.
If you’re early in your journey, make mistakes — just make sure you learn from them.
That’s how GitHub stops being scary and starts becoming powerful.
— Irshad