Local and remote repositories

- [Instructor] In this chapter, we're going to be looking at remote repositories, or as we call them in Git, simply remotes. In everything we've done up until now, we've been working locally on our own computer. Local Git repositories do not even need a network connection. We can use version control on our local files without sharing them with anyone else. However, Git becomes more powerful when we collaborate with others and that's what remotes allow us to do. With a remote server, we can take the changes we've made in our local Git repository and put them on a remote server so that other people can access them. They can view and download the changes that we've made, then they can make changes of their own and upload them to the remote server where we can then view and download them and Git makes this process easy. The remote repository often serves as a central clearing house for all changes in a project. Git is distributed version control. There's no real difference between a repository on the remote server or the repositories on the local computers of the collaborators. All Git repositories have commits, branches, a HEAD pointer and so on. It works exactly the same. The fact that one Git repository is designated as the central clearing house is really just a matter of convention. Let's take a look at the big picture of how this works. So we have our computer and we have a simple branch here called master that has a couple of commits in it. Now, we also are going to introduce a remote server. What we want to do is take our commits and we push them to the remote server so that other people can see them. We call this process a push. At that point, the remote server creates the same branch with the same commits with the exact same commit IDs referring to all of them. At that point, our collaborators have the ability to see those commits and they can pull them down and work with them. At the same time, Git also makes another branch on our local computer that's typically called origin slash and then whatever the branch name is. Here, I've called it origin slash master because it is mirroring the master branch. So origin master is branch on our local machine that references the remote server branch and it always tries to stay in sync with that remote branch. Right now, it looks like all three of these are in sync but it doesn't have to always be that way. We continue developing, we make a few more commits, then we do push. That code goes up to the remote server and it takes note of those changes in origin master. When other people make changes to the remote server and contribute them there, we need to pull those changes down so that we know about them. And we call that process a fetch. When we fetch the changes, at that point, they come in to our origin master branch because that what it's doing. It's keeping those two in sync. Fetch is essentially saying, sync up my origin master with the remote server version. But it does not bring code into our master branch. So now our computer knows about the change and we have it locally. At this point, we can get on an airplane and fly somewhere and while we're on that airplane, we'll have access to that commit, 923ea, but it's not in our master branch until we do a merge. At that point, it'll be brought into our master branch and everything will be back in sync. Now, this example is oversimplified and you can see that on my computer there are a lot of duplicate commits. Git doesn't do things that way. It's smarter about the way that it stores these commits. Like with other branches, We already know about the HEAD pointer that points to the tip of each branch. Let's take look at how it works with the remotes. So this is the same kind of example before. When we do a push, it creates the new commit it doesn't actually duplicate all those commits in the branch origin master. Instead, it just sets a pointer, a HEAD pointer for the origin master branch, a reference to that commit. Then when we make a new commit, Git moves our master branch pointer to that commit, everything now is not in sync, but when we finally do a push again, the commit gets pushed up to master, it moves the master pointer and also the origin master pointer at the same time. If someone else makes a commit, then of course the master pointer on the remote server moves. When we do a fetch, what actually happens is that it downloads that commit and it moves the origin master pointer to it but our master pointer stays pointing at the other commit. Then when we finally perform a merge, at that point, our master pointer moves to that last commit and it's a fast forward merge like the ones we've seen before. So as you can see, origin master is really just a branch. It's just like all the other branches that we've been creating and working with. The only difference is that it's a branch that tries to stay in sync with what's on the remote server. The reason that matters, is because it's possible for someone to make a commit on the remote server while we're also in the process of making a commit on our local machine. It happens all the time. I'm making changes to one part of my project. My collaborator is making changes to their part of the project. They put their changes on the remote server and then when I do a fetch, it brings those changes down to my computer. You see that origin master, does point to those two new commits but in the meantime, on my branch on my local computer, I've made a new commit that's labeled ba8ce. Now, our two branches have diverged, so we need to do a merge to bring them back together again and that process works exactly the same way as when we were working with merging branches in the previous chapters. Origin master is just a branch so we can merge them together. It can either be a fast forward merge or it can be a real merge that creates a new merge commit. This means that, generally speaking, the process you'll go through when you're working with a remote, is that you'll make your commits locally then fetch the latest code from the remote server to bring your origin branch in sync then merge any of your new work you just did into that branch and push the results back up to the remote server. If the process seems at all unclear now, If the process seems at all unclear now, it'll become second nature soon enough. it'll become second nature soon enough.