GitHub Remotes & Push

A remote connects repositories

Your local Git repository stores its own history. A remote is another repository location, often hosted on GitHub, that lets you share and retrieve commits. The conventional remote name origin is just a label; it is not a special server. Add the GitHub repository address with git remote add origin <repository-url>, replacing the placeholder with the address for your own repository.

Check the configured destination with git remote -v before sending work. A typo or wrong repository URL can publish to the wrong place, so confirm the owner and project name.

Push commits you intend to share

git push sends local commits to a remote branch. It does not upload every uncommitted file: Git transfers committed history. Stage selected files with git add, commit with a meaningful message, then push the branch. If the remote rejects the push because its history changed, read the message and ask for help rather than force-pushing blindly.

git status
git add path/to/change
git commit -m "Describe the change"
git push -u origin main

This is a generic workflow; your branch may have a different name. The -u option sets an upstream so later pushes can often use the shorter command.

Understand local and remote history

After your first push, main is your local branch and origin/main is your local record of the remote branch's last known position. They are not two names for the same thing. Your local branch can advance when you commit; the GitHub branch does not advance until a successful push.

git fetch origin
git status -sb
git log --oneline --graph --decorate --all

Fetch updates your remote-tracking information, not your working files. Status can now report “ahead” (local commits not yet shared), “behind” (remote commits not yet integrated), or both (diverged history). Without fetching, that information may be stale. When connected to GitHub, compare the latest online commit with the decorated log; opening the site verifies what was actually shared.

Handle a rejected push without erasing work

A non-fast-forward rejection means the remote cannot simply advance to your proposed history. It often happens when somebody else pushed, or when you created a GitHub repository with its own README commit. First fetch, inspect the graph and read the error. For a simple behind-only branch with a clean working tree, git pull --ff-only can safely advance to the remote's version without creating a merge. If the histories have diverged, this command refuses rather than choosing a merge or rebase for you.

Do not respond with force-push. Ask for help reconciling the two lines while preserving both people's work. If your work is only local, commit it before integrating somebody else's changes. Authentication and “repository not found” errors are different problems: check the copied URL, your signed-in account and repository access rather than changing history.

Keep secrets out of history

A .gitignore file tells Git which untracked files to ignore, such as local environment configuration or generated files. Add secret-bearing file paths to .gitignore before staging any changes. Ignoring a file does not remove it if it was already tracked, and deleting a secret in a later commit does not erase it from earlier history.

Never commit passwords, API keys, access tokens or .env contents. Check git status and review staged changes before committing. If a secret was pushed, revoke it immediately and follow the service’s incident guidance; do not assume a later deletion is enough.

Publish with confidence

Your earlier lesson introduced a first commit and push; now make the process deliberate. Confirm the remote, inspect the staged changes, write a specific message and push only intended commits. GitHub is a shared copy of your work, so treat every push as publishing rather than as a private backup.