Creating a Repository: Local First or Remote First, What Not to Commit, and the Push That Deploys It

Creating a repository is two commands or two clicks, and the order depends on where the code is. If the project already exists on your machine, run git init in its folder, add a .gitignore, make the first commit, then create an empty repository on GitHub and push to it. If the project does not exist yet, create the repository on GitHub with a README and clone it. Either way, the two things that matter more than the commands are the .gitignore you write before the first commit and the fact that a repository with a remote is one push away from a deployed site.

The hosting company’s own docs cover the clicks and the command-line tool cover the flags, and both are fine. What they leave out is the ordering decision that trips up every first project, the mistake of committing secrets and dependencies that the first commit makes permanent, and the reason a developer creates a repository at all, which is usually that something needs to be built, shared or deployed from it. This post is the version that starts from that reason.

Table of contents

• Local first: a project that already exists
• Remote first: a project that does not exist yet
• Public or private
• What not to commit, and what to do if you did
• The README, the licence and the first branch
• The push that deploys it
• How this fits the rest of the stack
• FAQ

Local first: a project that already exists

Most repositories are created for code that is already on a laptop. The sequence is short, and step two is the one people skip.

cd my-project
git init -b main
printf 'node_modules/\n.env\n.env.*\ndist/\n.DS_Store\n' > .gitignore
git add .
git commit -m "Initial commit"

-b main names the default branch main from the start, matching what GitHub creates, so there is no master to rename later. The .gitignore goes in before git add ., because the first commit is the one that captures everything in the folder, and a node_modules directory or a .env file that lands in it stays in the history even after you delete it. The git rename branch post is the fix if the branch was already created under the old name.

Then create the remote. On GitHub, use New repository, give it the same name, and leave every initialise option unticked: no README, no .gitignore, no licence. An empty remote accepts your existing history cleanly; one with a README has a commit yours does not, and the first push is rejected. Connect and push:

git remote add origin [email protected]:you/my-project.git
git push -u origin main

The -u sets the upstream so future pushes and pulls need no arguments. The git push origin main post covers what that flag is doing and the errors the first push produces when the remote is not empty.

Remote first: a project that does not exist yet

For a new project, go the other way. Create the repository on GitHub with a README, a .gitignore template for the language and a licence, then clone it:

git clone [email protected]:you/my-project.git
cd my-project

Now the folder already has a remote, an upstream branch and a sensible ignore file, and every later commit is a plain git add, git commit, git push. The command-line tool collapses both steps into one and can create the remote from an existing folder too:

gh repo create my-project --private --source=. --remote=origin --push

That single command initialises nothing locally that is not already there, creates the remote, adds it as origin and pushes. It is the fastest path for people who create repositories weekly, and worth learning after the manual version has been done once by hand.

Public or private

Private by default. A repository can be made public later with one setting; a repository that was public for an afternoon has been cloned by a crawler and its history is out. The cases for public are real: open source, a portfolio piece, something a deploy platform needs to read without a token. Everything else starts private, and the GitHub deploy connection on a hosting platform reads private repositories through an authorised app, so private does not mean undeployable.

What not to commit, and what to do if you did

The .gitignore from the first section is the minimum. The full list of things that should never enter a repository is short and every item on it has been committed by someone this week.

• Secrets. .env files, API keys, database URLs, private keys, service-account JSON. These belong in environment variables on the service that uses them, which is the environment variable discipline the framework docs assume.
• Dependencies. node_modules, vendor, virtual environments. They are reproduced from the lockfile; committing them makes the repository enormous and every diff unreadable.
• Build output. dist, build, .next, compiled binaries. The build produces them; the repository stores the inputs.
• Machine noise. .DS_Store, editor folders, log files.

If a secret was committed, deleting the file in a new commit does not remove it. Rotate the secret first, because it is already exposed, then rewrite the history to remove it if the repository is shared. The git remove commit post covers the rewrite; the rotation is the part that actually matters.

The README, the licence and the first branch

A README with three lines, what it is, how to run it, how to deploy it, is worth more than a template with badges. A licence file matters only for public repositories, and choosing one is a five-minute decision that becomes a legal question if postponed. Branch protection on main can wait until there is a second contributor; a solo project with a required review of its own pull requests is a solo project with a bureaucracy.

The one habit worth starting on day one is not committing directly to main for anything that could break the deploy. Create a branch, push it, merge it. The create a new branch from current post is the command, and the reason follows in the next section.

The push that deploys it

A repository with a remote is the unit that deployment platforms consume. Connect the repository, pick the branch, and every push to it becomes a build with a log and, if the build passes, a live route. That is why the first section put the remote in place before anything else was decided: it turns the repository from a backup into a deployment path.

On RunxBuild the connection is the GitHub app: authorise it, choose the repository and the branch, and the platform builds on push, whether the project is a static site, a Node, Next.js, Python, Go, Ruby, Java or .NET service, a Dockerfile, or WordPress. The build log shows what happened, environment variables set on the service replace the .env file the .gitignore kept out, and a bad push rolls back to the previous deploy. A static site deploys with 120GB of bandwidth included; a service starts on the Dev plan at $4 a month. The static site builds docs describe what the build step reads from the repository, which is the last piece of the picture: the .gitignore decides what is in the repository, and the repository decides what gets built.

How this fits the rest of the stack

Init locally and push to an empty remote when the code exists; create on GitHub and clone when it does not. Write the .gitignore before the first commit, keep secrets in environment variables, start private, and treat the remote as the thing a platform will build from rather than a backup. The RunxBuild hosting calculator shows what the project costs to run once the repository is connected and building, from a static site to a service with a database. Create the repository, make the first push count, and let the build log tell you what happens next.

Useful related references:

• git push origin main: What Each Word Does and Why It Fails
• Git Rename Branch: The Local Move, the Remote Move, and the Part That Breaks CI
• Deleting a GitHub Repository: The Danger Zone and What Goes With It
• Deploying from GitHub on RunxBuild

FAQ

What is a repository?

A folder whose full history Git tracks: every file, every change, and who made it. A local repository lives on your machine; a remote repository on a host like GitHub is a copy that other people and other systems, including deployment platforms, can read from and push to. The two stay in sync through push and pull.

Should I create the repository on GitHub first or run git init first?

If the code already exists locally, git init first, commit, then push to an empty GitHub repository created without a README. If the project is brand new, create it on GitHub with a README and .gitignore and clone it. Mixing the two, a local history and a remote README, makes the first push fail with a non-fast-forward error.

Public or private repository?

Private unless there is a specific reason for public, such as open source or a portfolio. A private repository can be made public later; a public one has already been crawled. Deployment platforms read private repositories through an authorised GitHub app, so private does not block deploying.

How do I upload an existing project to GitHub?

In the project folder: git init -b main, add a .gitignore, git add ., git commit. Create an empty repository on GitHub, then git remote add origin with its URL and git push -u origin main. The gh repo create command with —source=. and —push does the remote creation and the push in one step.

I committed a .env file by mistake. What now?

Rotate every secret in it immediately; deleting the file later does not undo the exposure. Then add .env to .gitignore, remove the file from tracking with git rm —cached .env, commit, and if the repository is shared, rewrite history to remove the file from past commits before pushing.