What is a remote repository?
So far, your repository has lived in one place: your computer.
A is a Git repository stored somewhere else, usually on a service like GitHub. It is still a Git repository, but it is available over the network instead of only on your own machine.
For the project we've been building, the local repository already exists. When we create a GitHub repository for it, the two repositories will not know about each other yet. To use them together, we'll connect the local repository to the remote repository's URL.
People often shorten remote repository to just remote. When someone says "push to the remote", they mean "send commits to that hosted Git repository".
Here is the path we'll follow in this chapter:
-
We already have a local repository on our computer. It has the commits we've made so far.
-
We'll create an empty repository on GitHub. This gives us a place online that can hold a copy of our project history.
-
We'll connect our local repository to the GitHub repository by adding the GitHub URL as a remote. The usual name for this first remote is
origin. -
After that connection exists, we can push our local commits to that empty repository on GitHub.
-
Later, if the GitHub repository has any new commits that our local repository does not have yet, we can pull those commits back down.
That connection step is the key part. Until you add a remote, your local repository does not know which GitHub repository it should send commits to.
There is one other common starting point: .
Cloning is what you do when the project already exists on GitHub and you want to get your first local copy. Instead of starting with git init, you clone the remote repository, and Git creates a connected local repository for you. Then, you work with it as usual.
In this course, we're doing the opposite: we started locally, and now we're connecting that local repository to GitHub.
With a remote repository, you can:
-
Back up your work: If something happens to your computer, your commits still exist on the remote server.
-
Work from more than one machine: You can push from one computer and pull the same commits onto another one.
-
Share work with a team: The remote repository becomes the shared place where people exchange commits.
If you own the remote repository, you can decide who may read it and who may change it. For example, an open-source project may allow anyone to clone the repository, but only selected people, called maintainers, can push commits to the main repository.
GitHub also lets people a repository. A fork is a separate server-side copy under someone else's account. That way, they can experiment in their own copy without changing the original repository.
Two words are easy to mix up:
-
Clone: make a local copy of a remote repository on your computer.
-
Fork: make a server-side copy of someone else's remote repository under your account. Then, you usually clone from this fork, rather than from the original repository. Updates from the original repo won't appear in your fork unless you explicitly pull them in.
If someone finds a bug in an open-source project, they can fork the project, fix the bug in their fork, and then suggest the fix by . If the maintainers like the change, they can bring it into the original repository.
Projects like Linux, .NET, Python, and VS Code are developed this way. You don't need that whole workflow yet, but it's useful to know what GitHub makes possible.
GitHub is a popular platform for hosting remote Git repositories. In this chapter, we'll create a GitHub repository, connect it to our local repository, and send our commits there.
Let's see how you can create a new repository on GitHub.
Take the course as it was meant to be taken: bite-sized progression, focused linear order, gradually unlock Gitopedia entries. Continue with real Git in VS Code/Cursor/Antigravity/Windsurf at any time.
but requires sign-in