Key concepts

Remote repository

In Git, a remote repository is a version of your project that is hosted on a network, such as on the internet or on a shared network. It serves as a central storage location for the project, allowing multiple people to collaborate on the same codebase. The remote repository is often hosted on a platform like GitHub, GitLab, or Bitbucket.

The main purposes of a remote repository are:

  1. Collaboration: Remote repositories enable team members to share their changes with each other. Each developer can push their local changes to the remote repository, and others can pull those changes into their own local repositories. This allows the team to work together on the same project, even if they are not in the same physical location.

  2. Backup: Storing your project on a remote server provides a backup in case something happens to your local machine. If your computer crashes or your local repository gets corrupted, you can still recover your work from the remote repository.

  3. Accessibility: With a remote repository, you can access your project from anywhere with an internet connection. This makes it easy to work on your project from different machines or locations.

  4. Continuous Integration and Deployment: Remote repositories are often used in conjunction with continuous integration and deployment (CI/CD) systems. These systems automatically build, test, and deploy your code whenever changes are pushed to the remote repository, helping to catch bugs early and ensuring that your software is always in a deployable state.

If your repository is connected to a remote repository (for example, origin), you'll usually have two sets of branches: local branches and remote-tracking branches. Local branches are your normal branches (e.g., main), while remote-tracking branches are branches that represent the state of branches in the remote repository (e.g., origin/main).

When you run git fetch, it updates your remote-tracking branches to reflect the state of the remote repository's branches. In other words, your main branch stays the same, but origin/main may be updated to match the remote repository's main branch. Then, you can merge or rebase your local branch with the updated remote-tracking branch to incorporate the changes. But this is a separate step from git fetch. Such a separation allows you to review the changes before merging them into your local branch.

Alternatively, you can use git pull to fetch and merge changes in one step, but this can sometimes lead to unexpected results if you're not careful.

Examples

Add a remote repository on the given URL to the list of remotes and assign it the alias origin:

git remote add origin https://github.com/user/repo.git

Pull the changes from a remote branch associated with the branch main on the remote repository origin, and if there are any changes, merge them into the main branch:

git pull origin main

Push changes to a remote branch associated with the branch main on the remote repository origin:

git push origin main

Clone the remote repository on the given URL to your local machine. You can add one more argument to specify the directory name where the repository will be cloned:

git clone https://github.com/user/repo.git

Compare the changes between your local branch and the remote branch:

git diff main origin/main

In these examples, origin is a conventional name for the default remote repository, but you can use any name you like. The main branch is often used as the primary branch in a repository, but this can vary depending on the project's conventions.

© 2024-2025 GitByBit.All rights reserved.

Hi! I'm Alex, creator of GitByBit.

And this is Gitopedia—a reference that summarizes knowledge in my Git course.

Gitopedia is designed to be a personal knowledge base. When you progress through the main Git course in VS Code, you unlock all of these topics, one by one, bit by bit. This gives you time to digest the information and gradually build the mental model of Git. Here's an example of how it works:

Learning directly in VS Code lets you practice Git exactly as you would in real life, doing real jobs, writing real code. In addition, the course has access to your actual terminal, so it can point out mistakes, suggest workarounds, etc.

The course is FREE, there are no Ads or other bullshit. There are optional premium add-ons you can purchase, mainly to support my work (regrettably, I have to eat every day), but that's totally up to you.

Learn Git in VS Code