Originally published on CodingCush.
To put your first project on GitHub, you create a repository on the GitHub website, then on your own computer you turn your project folder into a Git project, save a first commit, connect it to that repository, and push. Five ideas, in that order: repository, init, commit, remote, push. Beginners often think GitHub copies files the way a pen drive does. It does not. GitHub hosts a Git history — a record of snapshots you chose to save — and pushing means sending that history from your computer to GitHub. Once you understand that, the commands stop feeling like magic spells and start feeling like a checklist you can repeat for every project you ever build.
This guide assumes Git is installed and you have a free GitHub account. If the words Git and GitHub still blur together, read our short explainer on Git vs GitHub: what is the difference? first — two minutes there will make every step below obvious.
Step 1: Create the Repository on GitHub
Sign in to GitHub, click the plus icon at the top right, and choose New repository. Give it a clear, simple name in lowercase with hyphens, like my-first-website or student-login-php. Add a short description if you like. Choose Public if the project is for learning, your portfolio or a college submission that others should see; choose Private if it contains anything sensitive. For this first walkthrough, leave the options to add a README, .gitignore and licence unticked — your local project already has files, and starting with an empty repository makes the first push cleaner.
The official GitHub guide to creating a new repository shows the same screens with screenshots. After you click Create repository, GitHub shows a page with several command blocks. Keep that tab open — you will copy the repository address from it in Step 4. It will look like https://github.com/your-username/my-first-website.git. That address is your repository's home on the internet.
Step 2: Turn Your Project Folder into a Git Project
Now move to your own computer. Open a terminal inside your project folder — the folder that contains your code files, not a parent folder above it. Run git init. This creates a hidden .git folder, which is where Git stores the whole history. Nothing has been uploaded, nothing has even been saved as a snapshot yet. You have simply told Git: start watching this folder.
cd my-first-website
git init
git status
git status is your best friend. It tells you, in plain language, which files Git sees, which are ready to save, and what it suggests you do next. Run it after every step in this guide. Learning Git is mostly learning to read git status without fear. The messages look serious, but they are genuinely trying to help — like a sat-nav that only sounds stern.
GitHub Docs on creating a new repository — the empty repo comes first, then you push your local project to it.
Step 3: Stage and Commit Your Files
A commit is a saved snapshot with a message. Before committing, you stage the files you want in that snapshot with git add. For a first commit, adding everything is normal. Then git commit saves it. Write a short, honest message like "First commit: homepage and styles". Future you will read these messages when something breaks, so "stuff" and "final final v2" are not the gifts you think they are.
git add .
git status
git commit -m "First commit: add project files"
If Git asks who you are the first time, set your name and email once with git config --global user.name and user.email, using the same email as your GitHub account, then repeat the commit. Also add a .gitignore file before this first commit if your project creates files that should never be shared — passwords in config files, .env files, node_modules, vendor folders and large build output are the usual suspects. A secret pushed to a public repository should be treated as public forever, even if you delete it later.
Step 4: Connect Your Folder to GitHub (the Remote)
Your local project and the GitHub repository do not know about each other yet. The connection is called a remote, and by tradition the main remote is named origin. Copy your repository address from the GitHub tab you kept open and add it like this:
git branch -M main
git remote add origin https://github.com/your-username/my-first-website.git
git remote -v
The branch command renames your default branch to main, which is the name GitHub expects. git remote -v should list your address twice, once for fetching and once for pushing. If you typed the address wrong, this is the moment you will spot it — much better here than after a confusing push error. The official git-push documentation explains what push sends and where, for when you want the deeper picture.
Step 5: Push — Send Your Project to GitHub
Now the moment the whole guide has been walking towards. Push sends your commits to GitHub:
git push -u origin main
The -u part links your local main branch to the remote one, so future pushes become just git push. GitHub may ask you to sign in. In the browser-based flow, a sign-in window opens; on some setups you use a personal access token instead of your account password — GitHub stopped accepting plain passwords for Git pushes, and that is a security feature, not a bug in your setup. Follow the prompt your terminal gives you, calmly and once.
Refresh the repository page on GitHub. Your files should be there, with your commit message beside them. That quiet little page refresh is one of the nicest feelings in a beginner's coding journey — your project now exists in two places, with a history. Our older introduction, what GitHub is and why it matters, explains what to do with that presence next, from READMEs to sharing links with teachers and employers.
Your Daily Workflow After the First Push
From tomorrow, the rhythm is short: make a change, check git status, stage it, commit it with a clear message, and push when you reach a point worth sharing. Small, frequent commits are easier to understand and undo than one giant weekly commit. Think of each commit as saving your game before a boss fight — cheap to do, wonderful to have.
| Command | What it does | When you use it |
|---|---|---|
| git init | Starts Git in a folder | Once per project |
| git add . | Stages all changed files | Before each commit |
| git commit -m "message" | Saves a snapshot | After staging |
| git remote add origin URL | Connects to GitHub | Once per repository |
| git push | Sends commits to GitHub | Whenever you want to share or back up |
Frequently Asked Questions
Do I create the repository on GitHub or on my computer first?
Either order can work, but for a project that already exists on your computer, creating an empty repository on GitHub first — as in this guide — is the simplest path.
What is the difference between a public and a private repository?
Anyone can see a public repository; only you and people you invite can see a private one. Learning and portfolio projects are usually public. Client work and anything with secrets should be private.
Why did git push ask for a token instead of my password?
GitHub no longer accepts account passwords for Git operations. Use the browser sign-in flow or a personal access token when prompted — that is the expected, secure behaviour.
Can I push a project with passwords or API keys in it?
No — not safely. Remove secrets, list those files in .gitignore, and keep real keys in a local .env file that never gets committed.
What if git push is rejected?
Read the message. The common cause is that the GitHub repository has commits your computer does not have. Run git pull first, then push again.
Conclusion
Repository, init, commit, remote, push — five steps, and your first project is safely on GitHub with a real history behind it. Repeat the same checklist for your next project and it will feel ordinary, which is exactly the point. Ordinary, repeatable and backed up beats brilliant and lost on a broken laptop, every single time.
Top comments (0)