Put your project on GitHub

If your project only exists on your laptop, nobody evaluating your work can see it. Putting it on GitHub with a real commit history, not one giant "initial commit", shows how you actually work as well as what you built. Version control also protects your work and makes experimenting safe.

Why version control comes first

Git records snapshots of your project called commits. Each one captures what changed and why, so you can go back to a working version, compare changes, and try ideas on a branch without fear of losing anything.

GitHub hosts that history online. That gives you three things at once:

• A backup: a dead laptop no longer means a lost project.
• A public record: reviewers can read your code and see how it evolved.
• Collaboration: other people can open issues, suggest changes, and review pull requests.

Using Git and GitHub is a baseline expectation for developers, not optional polish. Getting comfortable with it on your own projects means you won't be learning it under pressure later.

Keep secrets and clutter out with .gitignore

Before your first commit, create a .gitignore file in the project root. Git will not track files that match its patterns. A typical JavaScript project needs at least:

node_modules/
.env
.env.local
dist/
.DS_Store

node_modules can be rebuilt from package.json with npm install, so it should never be committed. .env files hold API keys and passwords, which must never reach GitHub, even in a private repository.

Order matters: .gitignore only affects files Git is not already tracking. If you already committed a file, adding it to .gitignore does not remove it. You also need git rm --cached <file> to stop tracking it while keeping it on disk.

Create the repository and push

Create an empty repository on GitHub (no README, so histories don't conflict), then run this in your project folder:

git init
git add .
git commit -m "Set up project structure and basic page"
git branch -M main
git remote add origin git@github.com:your-name/your-project.git
git push -u origin main

main is the default branch name on GitHub. git branch -M main renames your local branch in case your Git still defaults to master. The -u flag links your local main to the remote, so later you can just run git push.

GitHub does not accept your account password for Git operations. Authenticate with an SSH key, or over HTTPS through a credential manager, gh auth login from the GitHub CLI, or a personal access token.

A commit history that tells a story

A reviewer who opens your repository and sees a single commit called "final" learns nothing about your process. Commit as you go instead, whenever you reach a small, working step:

• "Add form to create a task"
• "Save tasks to localStorage so they survive a reload"
• "Fix empty task being added when pressing Enter"

Good messages say what changed and, when it isn't obvious, why. Avoid "update", "stuff", or "fix" on their own, because they tell a future reader nothing.

Before each commit, run git status and git diff to check exactly what you're about to record. This catches accidental files, such as a stray .env or debug output, before they enter your history.

When things go wrong

Two situations catch almost every beginner.

Your push is rejected. A message like ! [rejected] main -> main (fetch first) means GitHub has commits you don't have locally, often from editing the README on the website. Run git pull --rebase origin main, resolve any conflicts, then push again. Don't reach for git push --force; it overwrites the remote history and can destroy work.

You pushed a secret. Deleting the file in a new commit is not enough, because the key still exists in the history and automated scrapers scan public repositories within minutes. Revoke or rotate the key with the provider immediately, then move it into .env and make sure .env is ignored. Treat any key that was pushed as compromised.

What to do now

Put your current project on GitHub properly:

1. Add a .gitignore that covers node_modules/, .env, and build output.
2. Run git status and confirm no secrets or dependency folders are staged.
3. Set up SSH or HTTPS authentication, create the repository, and push to main.
4. From now on, commit after each small working change with a message that explains it.
5. Open the repository in a private browser window and look at it the way a stranger would: are the files there, and does the history make sense?

Next, give that stranger a README so they know what they're looking at.