Why Use a Remote?

So far, everything you’ve learned about Git has been for repositories on your local computer, but you can also use Git repositories stored remotely. These are called remotes.

When working with remotes, you’ll use all the same commands you’ve already learned and just a few more. The best benefits of using a remote are:

• Disaster recovery
• Collaboration

This lesson shows you how to use GitHub because that’s a popular platform and one you’ll likely experience as a professional developer. GitHub offers some special services, but a remote repository can be on a company file server or even a thumb drive you pass among teammates. Remember, the only thing needed to make a directory a Git repository is the presence of the .git sub-directory. The Git executable operates on those files and the files in the working directory.

A remote Git repository offers disaster protection just as any offsite storage offers protection. The security and access control lists you use for offsite file storage can also be used for your Git files.

Using a Git remotes also enables collaboration. Anyone who can access the remote location can participate in creating branches, writing code, and merging branches back to main.

For a project with a small team, you could easily use meetings, chat and email to coordinate merging, and you wouldn’t worry much about access control because you’d trust all of the collaborators.

But what if you want to offer open-source code, where anyone on the Internet can access the repository, branch, and merge? Now, coordination becomes much more difficult. You might still have a small team of trusted collaborators, but perhaps multitudes of outside contributors are also offering changes and tweaks they’ve invented for your open-source project.

GitHub offers tools and practices to help manage collaboration on open-source projects. Although the ideas of forking and pull requests are used by most hosting platforms now, they first appeared at GitHub.

When you fork a repository, you make a copy of the repository under your own Github account. At this point, you can treat the repository as if you created it, making branches and merges as you need to. None of the changes you make to the fork get applied to the original repository without the explicit permission of the owner of that repository.

When using GitHub, anyone marked as a trusted collaborator on a repository can merge changes into the main branch. Anyone who is not a trusted collaborator can propose changes. A trusted collaborator can then review, approve, and merge those changes or not. The process of proposing changes is a pull request.

Though originally designed to allow anyone to propose changes to any open-source project, pull requests are now common on most projects because of their added safety. Even closed-source projects now use pull requests as a means to enforce code reviews, ensure all tests pass or enforce other checks before merging into main.

You’ll return to these ideas of forks and pull requests at the end of this lesson. But first, you’ll learn the mechanics of setting up a free GitHub account and linking your local repository to a remote.