What is Remote Repository in Git? How to Work With Remote Repo?

You might already know what is Git repository. If not, check the linked write-up for a better idea. It’s now time to understand exactly what is a remote repository in Git.

Remote repositories in Git are most often used as an intermediary between a user's local repository and the code hosting service where the project is publicly available. As such, they serve a different purpose than the original repository that comes preconfigured with every new local Git repository.

The origin repository of a local Git repository is stored on disk under the .Git/ directory in the user's home directory. It is meant to store all of the changes to the project's files and their history, including any file that has been deleted from the remote. 

This way, when you make changes locally, you can always push them up to your origin repository so that other team members can see your progress.

When using a remote Git repository, it is not necessary to store all of its files locally for purposes of committing changes or pushing them back up to the server. The only requirement is that you have a connection to the server through which you can push and pull changes at will.

Tags are a reference to a specific point in Git history. In this way, they're like branches, except they don't change. A tag is like a bookmark you can make in your code repository that's never overwritten, even after you've added new commits to the branch or merged branches together. You can think of tags as a  "landmark" in your code repository that you can use to find a particular state of your code.

In practice, tags are often used for version release points, where you can take a snapshot of your application at any time and give it an official name (e.g., 1.0.0). By tagging each release with its official name, you can then use that name to refer to the state of your application at that point in history. 

For example, if you then want to fix a bug or add functionality to 1.0.0 and make another release (1.1.0), you'd tag the new commit with the same name (1.1.0) as the first release—this way, you can ensure that all future references still work correctly and stay consistent with the initial 1.0 versioning scheme.

As part of the Git tutorial for beginners, we have here talked about Get alias with some examples.

It's worth mentioning that there isn't a straight Git alias command. Aliases are created using the Git config command and Git configuration files. Aliases can be generated locally or globally, just like other configuration options.

Let's make some examples to better grasp Git aliases.

1. global alias.co checkout $ Git config

2. global alias.br branch $ Git config

3. global alias.ci commit $ Git config

4. global alias.st status $ Git config

The preceding code example provides globally saved Git command shortcuts. The source commands are unaffected by the aliases. Despite the addition of the Git co alias, Git checkout would continue to be available.

The —global flag was used to generate these aliases, which indicates they will be stored globally.