Demo one: Getting started

Let's take a look at Version Control in action. First, we'll look at it conceptually, and then we'll actually do it. So in this diagram, the repository where your files are kept is represented by the large right-facing arrow and contains the different versions of our files over time. So at 9 a.m., you create a repository for your new project. This creates the empty database to which you can add files to be tracked. Oftentimes this is done by a command called Init. At 10 o'clock you create myprog.c and add just the main function.

Then you add it to your repository by checking it in. With each add or check in, Version Control systems ask you to compose a short message indicating why you are performing the check in. In this case, we'll say add myprog.c. Later on at 4 o'clock, you edit myprog.c again and add Func1 and save it back to your hard disk. This updates your working set, making it different from now what's stored in your repository, so you check in again. Now your repository has two versions of your file and two commit messages.

Later that night, you're so excited about the app you're building and how easy it is to use Version Control to keep track of what you're doing, you add Func2 and check it in again at 1 a.m. What a day. Now let's look at this in a live version using Git. Okay, let's roll up our sleeves and actually use a live Version Control system. We're going to use Git since it's one of the most popular systems currently being used in the software development world, and it's easy to use from the command line on Windows, Macintosh, and Linux.

We've installed Git by using one of the download links, and the Links.rtf file you'll find in the Exercise File directory. We're not going to go through the installation process here, we'll cover that in the chapter on Git. To begin, we'll open the Command window as I've done here, and the first thing we are going to do is validate the Git installation. We'll do that by typing git --version, and hitting Enter. What you should see is something like this, git version 1.7...whatever there is there in the rest of that line. That's going to vary, depending upon which build of Git you've actually chosen to download and install.

Now that we've got Git installed correctly, we're going to proceed. So the first thing we need to do is make a directory called FSVC1, for Fundamentals of Software Version Control, and then we'll change to that directory. Once we're inside that directory, type git init to create the repository. Git doesn't store its changes in a single database file representing the repository, rather Git stores the data about your files and directories and all their history in a hidden directory named .git.

To see that directory on Windows, we type dir /a, so there we can see the .git directory. We can verify that the repository is properly initialized by running git status. And as you can see, the message displays containing string to say "On branch master", "Initial commit", and "nothing to commit". This means that your working set is in the same state as your repository. So now Step 2. We're going to create myprog.c and add it to the repository.

On Windows we'll use Notepad, on OS X or Linux use our favorite Text Editor. So here we go, Notepad myprog.c. So first time we're going to create it, so we'll say yes, we want to create a new file, and now we're going to add Main. And then we're going to save it. Now our working set is different than the state of our repository. So every time you add new files, you have to tell Git to start tracking those files. You can do that in two stages or in one stage. In two stages, we're going to do it this way.

The first time you type git add and then star, and it's going to add all the files it doesn't know about. And then if we run git status again, you can see it now knows, oh, I have a new file. In order to get the file into the repository, we're going to commit it, so we're going to type git commit -a -m, and then a message, add myprog.c.

The first thing we're going to see is it didn't work because it said I don't know who you are. Every Version Control system needs to know who you are, so it can attribute all the changes that you make to you for your own purposes. That's pretty much you all the time, but when you're working in a team situation, that can be very crucial. So we're going to run these two commands that you see here on the screen. We're going to say git config --global user.email, and we're going to say you@example.com, and then we're going to say git config --global user.name, and we're going to say "lynda.com student".

Now of course, you want to put in your own email address here and your own name or user ID, if you're working in a team. Whatever it is, you've all collectively agreed on whether you're going to use your email aliases or your actual name, but for the purposes of the course, we're going to use these strings for your own purposes. Make sure you put in your own email and your own name. All right, now that we've done this, we can go back and try our commit again. And in this case, the commit worked. You can see that it said one file changed and one insertion.

So the string, add myprog.c is a sample of the kind of the message I mentioned before that you enter for each commit to indicate what you've changed. This message should be short and meaningful to either allow a future you or your fellow developers to understand why you made this commit. Note, on Windows the string should always be in double quotes. On OS X and Linux, it can be in single quotes, and we can verify that we've committed everything to the repository again by running git status, and you can see nothing to commit. That means we've added everything that we needed to.

Now, even though we've only taken one short step, we can now ask the Version Control system to tell us the history, and in Git you say git log -p, and you can see this is a full detailed history. It says that Author: lynda.com student at you@exampleemail.com on the date that you do it, added this file, and then it actually runs a diff and shows you the difference between the previous version and the current version.

Now in this particular case, the previous version was a new file, so what we see are the lines here in green which says we've added the main function. Now let's move on to make it change and see how versions are actually tracked. Let's reopen myprog.c and add Func1. And we'll save it back, and then once again as we did before, we'll commit it, so git commit -a -m "Add Func1 ()".

And you can see we made one file change, and we made two insertions. So now let's once again see how that change is tracked by Git by once again running git log -p. So now you can see that we've got at the top of the screen here the definition that when we added Func1, the full diff, you can see the blank line and the line with Func1 in green there. And then you can see down below that there is the information about the previous commit we made where it says add myprog, and you can see at the bottom of the screen now there is a Colon with a flashing cursor next to it.

When the list of changes is longer than a page, the paging mode is automatically invoked, so you need to hit the Spacebar until the Terminal window displays the word End and then type the letter Q to get back to your command prompt. So let's do the final step. I'll open up myprog.c one more time and add Func2. Once again, save our file and then do our commit again.

In case you're wondering what that -a is on the command line, the -m is for the message, the -a is basically making it possible for you to do git commits in a single step. By default, you can do git commits in two steps, like we did, and we added the first file where you added and then subsequently commit it. Most of the time when I use Git, I just do it all at once so that I can say make all of my changes, and then I don't have to worry about whether I've added files, or I have changed files by putting that -a in the Git commit line. It automatically adds all the new files so that it handles it all as a single operation.

So once again, we'll run git log -p, and we can see now that we've added Func2 and then we added Func1 and then we added myprog.c and finally we got to our end. Now you can see when you use git log -p, that is very verbose. There is a way of telling Git to get a shorter version of the history of the repository, so we do it like this. We say git log, now we give it some different arguments. In this case we say --oneline, because we want each revision to be on a single line, and we want to see all of them. So we say --all.

And here we can see in reverse chronological order our three commits with their commit messages. The number you see in yellow there at the left is the ID, sometimes called the change set ID or the check in ID. Each different Version Control system does something slightly different, but there's always an ID that uniquely identifies the set of changes that you made. So now let's ask Git to show us the difference between our initial check in and the most recent check in. The way we do that is we actually use these IDs and use the git diff command.

So we're going to say git diff, and we're going to put in the oldest one here, 6a3e577, now these numbers will be different for you. You'll have to look on your screen and see which GUIDs get created for this, and then we'll say 7555e83. And so you can see that it says in white that in the original one it only had the main function and in the most recent one, the Function1 and Function2 were added.

When we get into we are actually doing delete. You'll see that delete show up as red lines. All right, well that's about 80% of everything you need to know to use Version Control. Let's look at the remaining 20% again conceptually and then we'll see it in action.