Programming involves change and managing that change is the only way to make sense of it. You will learn about distributed repositories in this episode and how that enables you to work differently.
The file renaming and copying techniques that I described earlier form a crude form of version control but even more important is the fact that everything is local. All the backups are on your computer. That makes it difficult to share them with other people.
Maybe you could instead put the files on another computer that other people also have access to. That’s really what makes a computer a server instead of a client workstation. Anytime you have a computer designed to perform some service and make that service available for other computers to use, such as serving files, you turn that computer into a server.
Listen to the full episode to understand how Git makes use of servers to store repositories in a central location but at the same time treats all repos as essentially the same. You can also read the full transcript below.
Transcript
You’ll learn about distributed repositories in this episode and how that enables you to work differently.
The file renaming and copying techniques that I described earlier form a crude form of version control but even more important is the fact that everything is local. All the backups are on your computer. That makes it difficult to share them with other people.
Maybe you could instead put the files on another computer that other people also have access to. That’s really what makes a computer a server instead of a client workstation. Anytime you have a computer designed to perform some service and make that service available for other computers to use, such as serving files, you turn that computer into a server.
It’s possible to turn your own computer into a server. A server doesn’t always have to be an expensive and powerful computer sitting in a rack in an air-conditioned room with rows of other computers. Any time you have a computer connected to a network and it makes some service available for other computers to use, then you have a server.
Now, you wouldn’t want to use your personal computer for a server for a variety of reasons, but the point is that you could if you really wanted to.
One important aspect that makes a good server is availability. Since you don’t know when somebody will want to use the services offered by a server computer, it should be ready to accept requests at any time. You don’t normally turn servers off at the end of each day and you rarely even want to restart them.
A good version control system should be available for your entire team to use from each team member’s computer. And almost all version control systems can be run on a server computer so they’ll be available for use anytime somebody needs them.
But there’s a big difference in how some of these systems are designed.
The traditional way is more like taking your private backup files and placing them on a server so they’ll be available from a single location.
The system will likely make copies of the specific versions of each file that you want to work with on your local computer. It’s just faster to have the files sitting on your own computer than to always have to send the contents over the network anytime you want to read or open a file.
Some version control systems even try to get very elaborate by making your files appear to be copied locally but they really don’t exist on your own computer until the moment you try to access them.
It doesn’t really matter though if your version control system actually makes copies of the files on your local computer or just seems to do this. Because if you ever lose the network connection to that server, then you’ll lose access to any files that you don’t already have. This also means you lose access to other versions of your files.
So if you’re working on a laptop computer from home and want to switch versions, you won’t be able to until you connect to your office network and gain access to those server computers.
Or maybe you’re at work and need to switch versions. You open up your version control software and ask it to switch versions and you get an error that it can’t connect to the central version control server. Maybe the server itself just stopped working. Or the local utility company is digging outside your office and just cut through all your network connections.
These things happen and when they do, work stops for the entire development team.
But not if you’re using Git. That’s because while Git still has the concept of a central location where everybody on the team can access all the files in your project, Git doesn’t treat that central location as anything special.
Git is what’s called a distributed version control system. That means when you start working on a project, the first thing you do is clone the project repo. This creates a full copy not just of all the current files in the project, but you’ll have access locally to every version of every file in the entire project. It all gets copied to your local computer.
And it goes beyond just switching between old versions. You can make changes and commit them too. You can do all your work locally so you never have to worry about losing the connection with a central server.
In Git, the central server forms the meeting place where you can push any changes you make so that other people can then pull those changes down to their computers. Once you synchronize your changes with another Git repo, both repositories are then up-to-date with each other. At least for those changes that you push up to the central repo and for those changes that you pull down. You don’t have to synchronize everything if you don’t want to. The central repository is referred to in Git as the origin.
If your central server crashes and you lose everything it contained, then an older centralized version control system will need to be restored from a backup. And who knows how long ago that backup was created. But in Git, any computer that clones a repo is already a full backup. So you can recover from any client that’s recently synchronized changes.
Let’s say that you want to create a new project. Git makes this easy too. You just create your local repo in your project folder. Any Git repo is always self sufficient and can work all by itself. Once your project gets to the point where you want to make it available to others, then you just create an empty repo on the central server and push your local repo up to the server. This makes a full copy of all your changes on the server and it’s then available for other team members to clone. You don’t have to do this. You could just let other team members clone directly from your local repo. Remember that there’s nothing special about the Git repositories sitting on the central server. Your own local repo could just as easily serve as the origin repo for somebody else. The only real reason to use a central server to hold all of your Git repos is availability. A real server computer is more likely to always be available than your own computer.
The last thing I’ll mention is another term you might hear about Git called forking. A fork is like a cloned repository but it’s intended to be more separate. Maybe you like the work somebody has done in a particular repo and want to take the project in a whole new direction. Maybe the original project creators have one vision for where they see the project eventually going and you want to adapt the project to a completely different purpose. In this case, you probably don’t want or need to ever keep your work synchronized with the other team. You just want to start with what’s already there and continue on a different path. Forking allows you to create a new repo based on an existing repo and this new repo is all yours to do whatever you want. That is assuming of course that you follow the license of the original repo. Forking doesn’t give you permission to steal work. It just gives you the ability to split the work into another project.