Whether you’re using GitHub for non-code projects or building code projects with the help of AI, there are a few extremely common rookie mistakes that tend to show up early on. These mistakes don’t just affect how your repo functions—they directly impact how it’s perceived by others.
Some of these are minor, but a few can create real security risks and should be strictly avoided when uploading anything to GitHub.
#1: Not including a .gitignore file. A .gitignore file tells GitHub which files and folders not to track. Without one, it’s very easy to accidentally upload things that don’t belong in your repo—like system files, dependencies, or local environment folders. This clutters your project, makes it harder to navigate, and can even expose sensitive data. Most projects should have a .gitignore from the very beginning, and you can usually generate one in seconds based on your tech stack.
A .gitignore file is just a plain text file named exactly:
.gitignore
No file name before the dot, and make sure it’s not saved as .gitignore.txt.
Inside it, you list files and folders Git should ignore.
For example:
node_modules/
dist/
build/
.env
.env.local
.venv/
pycache/
.DS_Store
You do not need to write a .gitignore from scratch. GitHub has built-in .gitignore templates, and there are also online generators where you can type in things like “Node,” “Python,” “Windows,” or “React” and get a starter file.
The main goal is to avoid uploading local junk, dependency folders, private config files, and machine-specific files that only matter on your own computer.
If your project uses Node, the big one is usually node_modules/. If your project uses Python, common ones include .venv/, pycache/, and sometimes *.pyc.
If your project uses API keys or private settings, .env should almost always be ignored.
#2: Exposing secrets hard-coded into files. This is one of the few mistakes on this list that can cause real damage. API keys, tokens, passwords, and private URLs should never be committed to a public repo.
Once they’re pushed, they’re effectively exposed—even if you delete them later. Instead, use environment variables or config files that are excluded via .gitignore. If you’ve already exposed a secret, assume it’s compromised and rotate it immediately.
#3: Running into merge conflict weirdness. Merge conflicts happen when Git can’t automatically figure out how to combine changes. For beginners, they can feel confusing and intimidating, especially when you see blocks of strange symbols in your files. The key thing to understand is that Git is asking you to choose which version (or combination of versions) should win. It’s not an error—it’s a decision point. Learning how to read and resolve conflicts early will save you a lot of frustration.
This can happen in a very normal beginner workflow:
For example, you might make a quick edit to your README.md directly on GitHub’s website. Later, you open the same repo on your computer, edit the README in Notepad++, and then open GitHub Desktop.
From your perspective, it feels like you only edited one file. But from Git’s perspective, there are now two different versions of that file: one on GitHub and one on your computer.
This is why it is a good habit to “pull” changes in GitHub Desktop before editing files locally, especially if you recently changed something on GitHub’s website. Pulling updates your computer’s copy before you start making new edits.
A simple rule:
Before editing locally:
1. Open GitHub Desktop
2. Click Fetch origin
3. If it changes to Pull origin, click Pull origin
4. Then edit your files
5. Commit and push
GitHub Desktop saying there is a conflict does not mean you broke the project. It usually just means Git found two versions of the same file and needs you to choose how to combine them.
The confusing part is that GitHub the website and GitHub Desktop can feel like the same thing, but they are not automatically synced in real time.
Your local folder is its own copy. GitHub.com is the remote copy.
GitHub Desktop is the tool that helps move changes back and forth between them. When you edit in both places without pulling first, they can drift out of sync.
#4: Not including a README.md file. Your README is the front door to your project. It’s the first thing people see, and often the only thing they read. Without it, your repo has no context—no explanation of what it does, why it exists, or how to use it. Even a simple README with a short description and basic instructions is infinitely better than nothing. A good README turns a random collection of files into something that feels intentional and usable.
#5: Not adding any Topics. Topics help GitHub understand what your project is about, and they directly affect discoverability. When you don’t add topics, your repo is much less likely to show up in searches or be recommended alongside similar projects. Think of topics as tags or keywords—they help other people find what you’ve made. Adding a handful of relevant topics takes less than a minute and can make a big difference in visibility.
#6: No license (or not understanding licensing at all)
Without a license:
People don’t know if they can use your work
Some won’t touch it at all
By default, your code is technically “all rights reserved,” even if you didn’t intend that. Adding a simple license like MIT makes it clear that others can use and build on your work.
#7: Messy or inconsistent file structure. A messy file structure makes a project feel harder to understand than it actually is.
Things like:
Random files in root
Mixed naming styles (fileOne.js, file_two.js, file-final-final.js)
No separation of assets, code, docs
Structure = clarity.
#8: Not using Issues or Discussions at all. These are meant to be collaboration tools, but even if you’re the only person who will be working on or maintaining a repo, they can still be useful. For example, Issues can just be used to keep track of ideas you have for future changes or features you want added to a project down the road. Seeing 0 Issues on a repo is often a subtle red flag—it can signal that the creator isn’t really using GitHub as intended. Every project has issues. Nothing is ever perfect. So having at least a few is actually a strength signal, not a weakness.
Are there any rookie mistakes you remember making as a non-coder getting started with GitHub? I know I’ve been guilty of several (if not all) of the mistakes in this list—most of this is based on firsthand experience.
GitHub has a pretty steep learning curve for non-coders. It wasn’t originally built with us in mind, and that shows in a lot of the workflow and terminology.