Suggest an editImprove this articleRefine the answer for “What is a remote repository in Git?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**A remote repository** in Git is a copy of a Git repository that lives not on your computer, but somewhere else: on a server, in corporate infrastructure, or on a hosting service such as GitHub/GitLab/Bitbucket. **Key point:** it exists for exchanging changes and collaborating, and it also serves as a central storage and backup of the project's history.Shown above the full answer for quick recall.Answer (EN)ImageA remote repository in Git is **a copy of a Git repository that lives not on your computer, but somewhere else**: on a server on a network, in corporate infrastructure, or on a hosting service such as GitHub/GitLab/Bitbucket. It exists not "for Git to work" as such (Git works perfectly well locally), but **for exchanging changes and collaborating**, as well as serving as a **central storage/backup**. --- ## What exactly is stored in a remote repository A remote repository stores: - **commits** (the history of changes), - **branches** (references to commits), - **tags**, - Git's internal data (objects, references). Important: a remote repository is not "a folder of files", it is a **Git object database**, just like a local repository. Most often, a remote repository on a server is set up as a **bare repository** (without a working directory with unpacked files). This is normal: on a server, files are usually not edited directly, only commits are accepted and handed out. --- ## How a local repository differs from a remote one ### Local repository (on your machine) - contains your local history and branches, - has a working directory (the project's files), - you make commits locally, even without internet access. ### Remote repository (on a server) - serves as a synchronization point between participants, - lets you publish your changes and pull in others' changes, - is often treated as the "source of truth" for the project. Git is **distributed** by nature: every developer has a full-fledged repository. The remote is just a convenient shared exchange point. --- ## Why a remote repository is needed 1. **Collaboration** - one developer sends changes, another pulls them and continues working. 2. **Exchange and synchronization** - publishing your branches/commits for the team. 3. **Backup storage** - if your laptop breaks, the history stays on the server. 4. **Development processes** - Pull/Merge Requests, code review, CI/CD, checks, releases - all of this is usually tied to the remote repository. 5. **Separation of responsibility** - locally you can experiment, and you only send finished work to the remote. --- ## How Git "sees" a remote repository: remotes In Git, remote repositories are configured as a **remote** - a record consisting of: - a name (often `origin`) - a URL (the address to connect to) Example: when you run `git clone`, Git automatically creates a remote named `origin`, pointing to the source you cloned from. ### What `origin` is `origin` is **just a standard name**, not "a special server". A remote can be named anything (`upstream`, `company`, `backup`). ## How you connect to a remote repository (protocols) Commonly used: - **HTTPS** (convenient, tokens/passwords) - **SSH** (convenient for developers: keys, less hassle with tokens) - less often: `git://` and other options The choice of protocol affects the authentication method, but the essence of the remote repository does not change. --- ## A typical workflow with a remote repository 1. Pull the team's current changes: `fetch` or `pull` 2. Create/update your branch 3. Commit locally 4. Push the branch to the server: `push` 5. Open a Merge/Pull Request 6. After review, merge into the main branch 7. Everyone else pulls the changes (`pull`/`fetch`) --- ## Important points and frequent mistakes - A remote repository **does not update itself**: changes appear on the server only after a `push`. - `pull` can lead to conflicts because it tries to apply changes immediately. - `fetch` is safer when you want to first see what has changed and only then decide how to integrate it. - "Delete a file locally" ≠ "delete it on the server": it only reaches the server after a commit and a `push`. - You cannot "push" what is not in any commit: `push` sends **commits**, not "the state of a folder". --- ## Short final definition A remote repository in Git is a **Git repository located on a server** that serves as a **point of exchange and synchronization**: you **send** your commits to it (`push`) and **receive** other people's commits (`fetch`/`pull`), enabling collaboration and backup storage of the project's history.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.