Join Michael Lehman for an in-depth discussion in this video Working with check-in, checkout, and revert, part of Learning Software Version Control.
Okay, we've got a Git repository inside of our directory g1 here. Before we start adding things, let's set two git configuration items which will help us make sure that all of our changes are marked with our name and our email. So we say git config user.name and git config user.email. No, that's not my actual email. And now we can put in some code.
The content we're going to use is from the new project's haiku error message page. We're going to pick one that's happened to all of us before we started using Version Control. I'm going to create f1.c and main print f. With searching comes loss, and the presence of absence. "\My Novel\" not found.\n".
Now of course, this isn't going to ever happen to you again now that you started to use Version Control, but you know how that feels. So we'll save the file, and we'll exit. Now we'll add that to the repository in two steps. First, we have to tell Git to start tracking that file by saying git add f1.c, and we ask Git the status of our working set. It says there is a new file ready to be checked in. So now we'll add it to the repository, git commit, and you can see it created one file.
If we ask Git for the status, it says there is nothing new to commit. And if we ask Git for the log, you can see we have a message here that says there is our Initial check in commit message and three additional lines of information which we're going to look at here. The first line is the commit ID, or essentially changeset identifier. That's a 40-digit-long hexadecimal number, which is a GUID, or a Global Unique Identifier. Now, for most usage inside Git, you'll only need to type the first four or five characters of that GUID, so don't get scared by the fact that it's going to be starting to ask you to type in 40 digit numbers.
But you have to type in at least as much of that in order to be able to uniquely identify a changeset as necessary. So especially on your own system, it's probably four digits. When you start working with more people, it's probably five or six at the most. So now let's make a change so we can see Git's versioning in action. We'll once again open up f1.c, and we're going to change My Novel to Website, maybe a more appropriate message for the internet age. And now we're going to check it in again, but this time we're going to use an editor feature that's built into Git in order to do our commit message.
So we're going to say git commit -a, and Git opens up in this case, Vim, a editor that allows you to put in your commit message. So we're going to say Changed my novel to website, and since this is Vim, it understands all those wonderful VI commands that you might know and love. In this case, what I do is I hit the Escape key and then I type :wq to Save it and Quit, and now it does the commit. And if we do git log, you can see now we have two changes, both our Initial check in and Changed my novel to website.
If you just want to see the changeset IDs and the comments, you can say git log --one line --all, and now we have--you can see the first seven digits of each one of those changeset IDs and the commit message. So now let's make another change and then look at it and decide if we want to roll it back. So once again, we're going to open up f1.c, and we're going to change Website to Webpage, and we're going to Save the file. Now, if we want to see the difference between our working set and what's in the repository, we can say git diff, and you can see it shows the one line has changed from website to web page.
Now, this show the difference with all files that are currently changed in the working set. If you want to see changes just for a single file, you can say git diff and just put in the file name. Now, in our case it's going to be exactly the same, but if you had 25 files, that might generate quite a bit of output. You can also ask for the differences between the working set and a specific changeset. So if we do git log, we can see we've got our two change sets. Let's ask for the difference between our working set and not the most recent one where we changed My Novel to Website, but the initial one where initially we checked it in and where we had My Novel.
So we'll say git diff, and we're going to put in 87b53, and we'll see what happens. So now you can see the difference between that commit which we called our Initial check in and the current state of our working set. You can see our current working set in green here says Webpage and the Initial check in said My Novel. Now, your changeset IDs are going to be different than these. You'll need to run git log on your system and type in the first five digits of the actual IDs on your system, because GUIDs are partially generated by the Mac address for your Ethernet adapter in your computer and so it will be clearly different than the system on which we're recording this.
So now let's roll back to our most recent commit. So we'll say git checkout HEAD f1.c. If we type f1.c, you can see we're back to Website. You can also revert to any particular revision, not just the topmost one, by using the checkout command. So we'll say git log, and now we're going to revert back to the initial one, so we're going say git checkout 87b53 f1.c, and now if we type f1.c, you can see we're back to My Novel.
Note, none of the changes in your repository have been lost. You're just updating the working set to the one that you want. So for example, we can go back to git checkout HEAD f1.c, and we're back to Website. All right, that's the basic working flow of checking in, checking out, and reverting with Git. Let's move on to tagging and labeling with Git.
- Comparing centralized vs. distributed systems
- Saving changes and tracking history
- Using revert or rollback
- Working with the GUI tools
- Using IDE and shell integration
- Installing different systems
- Creating a repository
- Tagging code
- Branching and merging code
- Selecting a software version control system that's right for you