Join Kevin Skoglund for an in-depth discussion in this video Using local and remote repositories, part of Git Essential Training.
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 able to do just on our own computer. We don't even need a network connection. We can do version control just on our local files and not share them with anyone else, and that's very effective and Git allow us to do that. But Git becomes even more powerful when we're able to collaborate with others, and that's what remotes allow us to do. The concept is that there is a remote server, and we'll take our changes that we've made and put them on that remote server so that other people can then see them. They can then download the changes that we've made to their repositories, they can make changes of their own, upload those back to the remote server, and we can pull those back down into our repository to get their changes.
It makes this remote repository sort of a central clearing house for all of these different changes that are going on, and that remote server is just simply a Git repository. Remember that Git is distributed version control. There's no real difference between the different repositories, so there's not a big difference between the server and our computer or the client. The only difference really is that the server is running some Git software that allows it to communicate with lots of different Git clients at the same time, but the actual repository where those changes are being stored, is just simply a Git repository; it has commits, it has branches, it has a HEAD pointer. It works exactly the same, and the fact that that Git repository is the central clearing house is really just a matter of convention.
We've all just agreed that we're going to use this one repository as the place where we all sync up our changes, but it doesn't have to be, it's still just a Git repository. Let's take a look at the big picture. So we know that we have our computer, and we know how to have just a simple branch called master with commits in it. Now we're going to introduce a remote server. What we want to do is take our commits and put them on the remote server, so other people can see them. The process that we used to do that is called a push. So we push our changes to the remote server, or you can say you pushed them up to the remote server.
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 our commits. At the same time, Git also makes another branch on our local computer that is typically called origin slash and then whatever the branch name is. Now that's by convention, we'll talk about how we can change that name, it doesn't have to be origins, but in this case we'll stick with the default. So origin/master is a branch on our local machine that references the remote server branch, and it always tries to stay and sync with that. Right now it looks like all three of them are in sync, but it doesn't always have to be that way.
We continue developing, we makes some more commits on our master branch when we're ready to share those commits, again, we do a push, so we push that code up to the remote server, and it makes note of the change also in our origin/master branch, the one that tries to stay in sync with the remote one. 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 the way that we do that is with what's called a fetch. So we fetch the changes, at that point they come into our origin master branch, because what we're doing is keeping those in sync. Fetch is essentially saying sync up my origin master with the remote server version, but it does not bring it into our master branch.
Now our computer knows about the change, we have it locally, if we get on an airplanes and fly somewhere while we're on the airplane, we'll have a copy of that commit that 923ea, but it won't be in our master branch until we do a merge, and at that point then it'll be brought in to our master branch, and we'll be back in sync. Now this is an over simplified example, because you might notice that on my computer I have lots of duplicates. You can see that I have those same Git objects listed twice on my own computer. In realty, it doesn't store them twice. Git is smart about reusing these objects, because they're exactly the same.
So Git uses pointers instead, to point to that, and we know about the HEAD pointer. So let's take a quick look at how that works just to make sure that that's clear. I think for illustrative purposes, it was good to see it as two separate branches with two sets of commits. But in reality, we have a HEAD pointer for master that points to the third commit, when we do a push and push it through remote server, it creates the commits there, and moves the HEAD pointer for master to the third commit, and then also adds another pointer that points to the same commit on our local computer. It doesn't actually duplicate those three objects.
When we then make a new commit, it moves our master pointer to the commit, when we do a push it creates that new object on the remote server and moves the pointer, and also increments origin/master. Then when new changes come into the remote server from someone else, of course, it moves the master pointer to point to that latest commit. When we do a fetch, it brings that new Git object down onto our computer and moves the origin pointer to point to it, but our master ones still doesn't. We have to first do a merge, and we know that would be a fast- forward merge, that's what we would call that, in this case where it just moves all the way to point to the same commit.
So as you can probably see, origin/master really is just a branch, it's just like the other branches that we're working with. The only difference is that it tries to stay in sync with what's on the remote server. The reason that matters is because it is possible for someone to make a commit on the remote server while we're in the process of making a commit on our local machine. All right, it happens all the time. I'm making changes to one part of the project, my collaborator is making changes to their part of the project, they put theirs up on the remote server, my origin master, once I do a fetch, the state of our two servers would look something like this.
You'll see that origin/master does still include those objects that are in the remote branch, it did stay in sync with that, but in the meantime I've got a new commit called ba8ce. So now that our two branches have diverged, we need to do a merge to bring them back together again, and that process works exactly the same way as we saw when we were working with emerging branches. Origin/master is just a branch, so we can merge them together and then the next time we do a push, our master changes will be merged in and sent off to the remote server.
So generally speaking, the process that you go through when you're working with a remote, is that you'll do your commits locally, then you'll fetch the latest from the remote server, get your origin branch in sync, then merge any of the new work you did into what just came down from the server and then push the result back up to the remote server. If the process seems at all unclear now, it'll become second nature soon enough.
- Exploring the history of version control
- Installing Git on Mac, Windows, and Linux
- Initializing a repository
- Writing useful commit messages
- Understanding the Git three-tree architecture
- Tracking when files are added, edited, deleted, or moved
- Viewing change sets and comparing versions
- Undoing changes and rolling back to previous versions
- Ignoring changes to select files
- Creating and working with code branches
- Merging branches and resolving merge conflicts
- Stashing changes for later
- Working with hosted repositories and remote branches
- Developing an effective collaboration workflow
Skill Level Beginner
Q: In the Chapter 10 movie "Configuring the command prompt to show the branch," when I type the function "__git_ps1," I do not get the expected result.
A: The function "__git_ps1" was recently moved to a new file, .git-prompt.sh, as described here: https://github.com/git/git/commit/af31a456b4cd38f2630ed8e556e23954f806a3cc.
We will update the video. In the meantime, you may do the same steps you do for .git-completion.bash, but a second time using ".git-prompt.sh" as shown here: https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh.
Q: When I use the code the instructor advises in the above video ("git config --global user.name "Nelda Street"), I still get an "Illegal Instruction" error. I have OS 10.6.8. Am I doing something wrong?
A: The current installer version of git isn't compatible with older Mac OS versions.
1. To add "-mmacosx-version-min=10.6" as described here:https://stackoverflow.com/questions/14268887/what-is-the-illegal-instruction-4-error-and-why-does-mmacosx-version-min-10https://stackoverflow.com/questions/10177038/illegal-instruction-4-shows-up-in-os-x-lion
2. Or to use the version of git that comes with Xcode, or to use homebrew to install git instead.http://superuser.com/questions/697144/installed-git-not-sure-how-to-get-it-working