Remote Repository

You might say

My commits only exist on my computer. How can others see them?

A repository accessible elsewhere that exchanges commits with a local repositoryYou commit B locally, while remote main (origin) on GitHub still points to A; B exists only on your computer until push sends it to the remote. A teammate can then build commit C on the remote history. If the remote has commits missing locally, a direct push is rejected. Pull fetches first, then integrates remote commits using the configured merge or rebase behavior. origin is a common remote name; pushing to a repository does not mean a website has been deployed.

Know first

Push

Remoteorigin

Commit history · local main and remote main (origin)

Before pushLocal A → B; remote A

Push succeedsBoth have A and B

Teammate pushes CLocal A → B; remote main (origin) A → B → C

After pull and integrationBoth have A, B, and C

git pull fetches first; fetch updates the local origin/main tracking reference to A → B → C, then configured merge / rebase integrates it. Here local main can fast-forward to C.

A commit is local until pushed. Syncing it to a remote does not mean the site has been deployed.

You can say this to an AI Agent

Run git fetch origin, then compare local main with the updated local remote-tracking reference origin/main. If remote main (origin) has a teammate’s C, explain what it changes, then run git pull using the project’s configured merge/rebase behavior and resolve any conflicts. Confirm C is preserved and the page still works before pushing; explain that push syncs to the remote but does not mean the site was deployed.

When to use it

Check the linked remote addresses
$ git remote -vorigin https://github.com/you/my-first-page.git (fetch)
Name the default remote origin
$ git remote add origin https://github.com/you/my-first-page.gitCloning usually sets up origin automatically
After a rejected push, review remote commits, pull to integrate them, then decide whether to push
git pull→git push→Push succeeded ✓
Clone copies the remote’s current commits and commonly names that remote origin
$ git clone https://github.com/you/my-first-page.gitCloning into 'my-first-page'...

When NOT to use it

Commit secrets or .env files and push them
.env holds keys; after pushing anyone can read themNever commit keys or passwords to a repository
Force push over remote history after a rejection
git push --force erased the 3 commits a teammate just pushedWhen rejected, pull and merge instead of force pushing
Push to the wrong remote address
Pushed to someone else's repository addressConfirm the address with git remote -v before pushing
Assume pushing means the site is deployed
git push ✓→The site did not update

Anatomy

https://github.com/you/my-first-page.git

Points to a network-accessible repository; origin is a common nickname, and renaming it does not change the repository content.

Variants

remote -v

git remote -v

See which remote addresses this repository is linked to

remote add

git remote add origin https://…

When the local repository has no remote address yet

push

git push origin main

Send local commits to the remote repository

pull

git pull origin main

Fetch remote commits, then integrate them locally using the configured behavior

Typical use cases

Local commit B has not been sent to the remote

Before push · B is local only

Shared starting point: A Local main: A → B (HEAD) Remote main (origin): A

Commit BNot sent yet

Hosted repositoryStill at A

A commit first exists in the local repository. The remote branch moves only after a successful push.

Both sides have A and B after push

Push succeeds · both sides have A and B

Local main: A → B (HEAD) Remote main (origin): A → B

Where commit B exists
Local repository	Has B
Remote main (origin)	Has B

What push doesSends reachable commits to the remote

A remote commit is available to others; deployment still depends on a separate deployment process.

A teammate adds C and local push is rejected

A teammate pushes C · your local copy has not fetched it

Local main: A → B (HEAD) Remote main (origin): A → B → C

Where commits exist now
A	Local + remote
B	Local + remote
C · teammate's fix	Remote; not local yet

git push origin main ! [rejected] main (non-fast-forward)

The remote has C, which your local branch lacks. Git rejects a direct push to protect the other commit; inspect and integrate C first.

Pull integrates C according to configuration

After pull · local also includes the teammate's C

git pull origin main Local main: A → B → C (HEAD) Local tracking ref origin/main: A → B → C Remote main (origin): A → B → C

First, pullFetches remote commits

Then, pullIntegrates using configured merge / rebase

In this exampleLinear history can fast-forward to C

Review C, then integrate according to the project's pull configuration. Keeping the teammate's commit brings both histories back in sync.

Recommended tool

Web fine-tuning tool · Selector Pro

Select page elements for precise AI edits

Click a button, text, or card, note the change, then copy its exact location to AI.

Open Selector Pro website

Local has A and B, while the remote also has a teammate’s C; push is rejected. What next?

A. Review C, then use git pull with the project’s configured integration behavior before deciding whether to pushB. Run git push --force to overwrite the remote’s CC. Rename local main and push it to the same remote