Join James Williamson for an in-depth discussion in this video How Git works, part of GitHub for Web Designers.
Before we go into the basic commands of using Git. I want to take a moment to review how Git actually works. If you understand the basics of how it operates it's a lot easier to learn those individual commands. Well Git works by taking snap shots of your project. Each time you save its current state, which you do by making what is known as a commit. If a file's changed, it's included as part of the snapshot. If it's not, a reference to the earlier file is used. Going back to an earlier commit simply restores the file system to one of these earlier snapshots.
Now, I want to point out something about this slide. You'll notice that the newer commits, which are on the right-hand side, actually point back to the older commits, which are on the left-hand side. That's a little counterintuitive, or at least it was for me when I first started using Git, and I would see diagrams like this. I'd be like, wait a minute, I thought this project built on itself, so shouldn't those arrows be pointing the other way? Well actually what's happening is those newer commits are actually pointing back to the older commits cause they're saying, okay here are all the changes in this commit, and anything that didn't change you're going to find in this old commit.
So it can keep going all the way back to the initial commit if it never changes again. So, that's why those arrows are pointing backwards because the newer commits are indeed pointing back to and referencing those older commits. You'll also notice on the slides that I'm using this sort of strange looking string of characters, I've got a bigger version of it here, that represent each of these commits. And that's because in Git a unique 40-character string, which is referred to as a hash. Represents each of the commits themselves. Now, don't worry about memorizing all 40 or so characters, usually Git shortens to around seven characters or so, when referencing commits, which makes them a lot easier to identify and remember.
Now I want to physically show you what happens when you initialize a Git repository. Again, which is sometimes referred to as a repo. When you do that, a Git directory is created inside of your project that contains all of the metadata. And the database necessary for tracking that particular project. So what I've done is I just put, you know, folder of the desktop called project and then I initialized it as a gitrepo. When I click on this I can actually see that I've created a folder called git. Now on this Mac, I have turned hidden files on. So I went in terminal and I typed in a little command that since I want to be able to see all my files.
Which is the only reason I can really see it. But if I click on this, I can see that here's all of my files necessary to track this particular folder. So this is a git repo, and these are all the files. They're going to help me. They're going to be the database, all the meta data, that sort of thing. So you do physically add something to the directory structure when you initialize a git repo. Now, this also establishes the three basic areas of your project and that would be the working directory, the staging area, and the Git repository. Now your working directory contains the current state of your files and that's going to be based on the current commit that you have.
The staging area contains an index that's going to be contained in your next commit. Which is usually the files that have been added or modified since the previous commit. Now once the commit is made. The commit is added to the git repository. And the process starts all over again. What's really interesting about this workflow is the amount of control that it gives you. Over what is contained in each of these little snapshots. Each file that git tracks exists in one of three states: unmodified, modified, or staged.
Now if a file hasn't been changed since the last commit, it's seen as unmodified and won't be added when you do your next commit. If a file has been changed since the last commit. It's seen as modified, meaning that it's available to be part of the next commit. Now, that doesn't happen automatically. To add a modified file to a commit, it must first be staged. Staging a file simply moves it into position to be added to the next commit. This creates a workflow where files are modified, staged, and then saved as part of a commit.
Now that might seem at first when you first hear about that that it introduces sort of an extra step in the process of making commits but. In reality this is a good thing because it allows you to choose which modified files to add to every single commit you make. And this would allow you to, for example, experiment with a file for a little bit. And only add it to a commit when it's ready. Now one of Git's most powerful features is its ability to create branches. At any point, you can take an individual commit and create a new branch from it. You can then develop and experiment with this branch without affecting your master branch.
This can either be spun off into a separate project, or you can even merge it back into the master branch and add all of these changes. All of this makes a lot more sense once you've done it a few times. So in the next series of exercises, we will experiment with these concepts as we learn some of the basic get commands.
- Creating an account
- Installing GitHub
- Git basics
- Adding files to Git
- Checking differences
- Creating, switching, and updating branches
- Creating a new GitHub repository
- Managing files with the GitHub client
- Working with collaborators