How to Push Code to GitHub for Beginners in Seven Steps

Your small app runs locally, but its code still lives only in a project folder. By the end of these steps, the reviewed files will be in a GitHub repository you can open in a browser. You need a GitHub account, Git installed, and a terminal open in that folder. For beginners, pushing code to GitHub is easier when you check what will be shared before running the push command.

The commands below assume this project has not already been set up as a Git repository. They also assume you want to create an empty repository on GitHub rather than connect to one containing files. If your coding environment already manages Git for the project, inspect its existing repository and remote before running the setup commands.

Prepare the local project

Step 1: keep private and generated files out of the project you share

Inspect the folder before Git starts tracking it. Put secrets in environment variables rather than source files, and add local environment files, dependency folders, and generated output to .gitignore as appropriate for your app. For example, a project that uses a local .env file should list .env in .gitignore. Check your source files too: ignoring a file will not remove a secret copied into another file. If a secret has already been exposed, remove it from the project and rotate it before sharing the repository.

Step 2: create an empty GitHub repository

Create a repository in your GitHub account and give it a name you recognize, such as invite-prototype. For this procedure, leave the repository empty rather than initializing it with a README, license, or .gitignore; you can add those files locally later. Copy the repository's HTTPS address from GitHub. Its shape will look like https://github.com/YOUR_USERNAME/YOUR_REPO.git, with your own account and repository names in place of the placeholders.

Step 3: initialize Git in the project folder

From the terminal in your local project folder, run:

git init -b main

This creates a local repository with main as its starting branch. Run git status to confirm Git sees the folder. If Git says the folder is already a repository, stop and inspect its branch and remote instead of treating it as a fresh project. Keeping the existing setup intact is safer than adding a second remote without knowing where it points.

Commit and publish the reviewed files

Step 4: stage the files you intend to share

Run git add ., then inspect the staged list with git status. This is the moment to catch an unexpected configuration file or generated folder. If something should not be in the commit, remove it from the staging area with git rm -r --cached PATH, replacing PATH with the file or folder path, and update .gitignore where appropriate. Repeat git status until the staged list matches what you meant to publish.

Step 5: commit that version locally

Give the reviewed files a short description:

git commit -m "Add initial invite prototype"

A commit is a local saved version; it has not reached GitHub yet. If Git asks for your name or email, configure your Git identity using the instructions it prints, then rerun the commit. git status should show no pending changes if you have not edited anything since staging. Future commits can be smaller, such as one for a form change and another for an authorization fix.

Step 6: connect the local repository to GitHub

Add the HTTPS address you copied in step 2:

git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO.git

Replace the placeholders before running it. git remote -v shows the address Git will use for fetching and pushing. Check the account and repository name rather than assuming a successful command means you chose the right destination. If origin already exists, inspect it before changing anything; the folder may already be connected to a repository.

Step 7: push code to GitHub and verify it arrived

Send your local main branch to the connected repository:

git push -u origin main

Git may ask you to complete an authentication flow. Follow GitHub's current instructions for your Git setup rather than entering your account password as a Git credential. Once the command succeeds, open the repository in your browser and confirm that the expected files and commit appear. Check again for anything private that should not have been uploaded. For later changes, review the files, commit them, and run git push on the connected branch.

Leave a useful note for the next build session

A successful push tells you which version reached GitHub. It does not explain why you changed a permission check or which AI-generated suggestion you rejected. After publishing the invite prototype, record the next action and any test you still owe it, especially a non-owner invite attempt. That gives you a starting point when you return after a few days away.

If you want those decisions beside the work you plan to continue, save your build notes in VibeCrumbs.