Is it safe nowdays creating public repos intended for small projects?

[rodrigcasio]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

GitHub Skills

Body

hello:) 👋 So, this is the first time using the community forum, and I do have a question that I would appreciate being answered by more experienced GitHub users, as I always intend to learn 😅

I do not consider myself an expert in using GitHub, because I started using it last year. I've been trying to understand its purpose while also learning how to code the basics of multiple programming languages, saving whatever file or small program I do in its respective public repo, for example: Cpp-projects, JavaScript-projects, C-projects- etc. Trying to keep it modular and professional in my own repos.

Most of the time, I create pull requests for my owned repos too, just to practice the CLI commands and merging them, just for fun and practicing an appropriate and professional workflow, simulating as if I'm working with a team in a repo(Hopefully in the future, hehe)

But I recently created a public repo and started a small project creating a Unix shell, and I was wondering if I should change it to a private repo. I know that thousands of people have done this type of project, and probably it wouldn't matter, but I just wanted to know if it is better to keep this type of repository private, and also, like the ones I save basic scripts of the programming languages I'm learning, changing them to private.

thanks,

@rodrigcasio

[ShubhamTiwari007xx]

What you described — creating separate repositories, practicing pull requests on your own repos, using branches, merging changes, and simulating team workflows — is exactly how many developers learn professional development habits before working in real teams.

A few important points:

• Public repositories for learning projects are completely normal.
• A Unix shell project is also a very common educational project.
• Employers and collaborators often prefer seeing learning progress publicly rather than only polished “perfect” projects.

Keeping repos public has benefits:

• You build a visible portfolio.
• You learn version control in real conditions.
• You get comfortable writing commits, PRs, README files, and project structure.
• Future recruiters or collaborators can actually see your growth.

You only really need private repositories if:

• The project contains secrets/API keys/passwords.
• You are working on something proprietary.
• You genuinely do not want the code visible yet.
• You plan to commercialize something privately later.

For beginner/intermediate learning projects like:

• language exercises,
• small scripts,
• data structures,
• shell implementations,
• CLI tools,
• practice repositories,

public is usually perfectly fine.

Your workflow practice is also smarter than you think. Many beginners only “push code.” You’re already practicing:

• branching,
• pull requests,
• merge flow,
• repository organization,
• CLI usage,
• modular repo structure.

Those are real professional skills.

One suggestion:
Instead of hiding beginner projects, keep them public but improve them gradually:

• add a README,
• explain what you learned,
• document commands,
• add screenshots/examples,
• use meaningful commits.

That progression itself becomes valuable.

For example, a repo like:

“Simple Unix Shell — learning process while studying processes, pipes, and system calls in C”

looks completely respectable for a learner.

Also, experienced developers usually do not expect junior developers to have perfect codebases. They mainly look for:

• consistency,
• curiosity,
• ability to learn,
• project completion,
• understanding of Git workflow.

And honestly, your habit of simulating teamwork with your own pull requests is something many beginners never even try.

[rodrigcasio]

thank you for your reply @ShubhamTiwari007xx

[ghostinhershell]

Hi @ShubhamTiwari007xx, thanks for taking the time to answer!

@rodrigcasio if the response above helped, please feel encouraged to mark it as the answer. If not, let us know if you have further questions or post the solution if you've resolved it on your own. It would be helpful for other users who might experience this in the future to quickly find the answer. 😄

[QngChan]

Make it public. Because u will learn how to make tidy and clean repos thats a basic thing dont mind that much just work on ur project

[vincere-mori]

Yes, it is normal and generally safe to keep small learning projects public.

The main things to avoid are not about the code being simple, but about accidentally publishing private material:

• no API keys, tokens, passwords, cookies, SSH keys
• no .env files with real values
• no personal documents or real user data
• no copied code/assets unless the license allows it
• no hardcoded local paths that expose more than you want

A good pattern is:

.env          # ignored
.env.example  # committed, fake values only

and a .gitignore that excludes build output, dependency folders, editor files, and secrets.

For a Unix shell project, public is perfectly fine. It can actually help because future employers or collaborators can see how you work. Make it private only if it contains something personal, security-sensitive, or unfinished in a way you specifically do not want visible.