Watching:

Demo two: Handling the "oops"


show more Demo two: Handling the "oops" provides you with in-depth training on Developer. Taught by Michael Lehman as part of the Fundamentals of Software Version Control show less
please wait ...

Demo two: Handling the "oops"

Picking up from where we left off before we'd created a repository and made a few check-ins, and you check things in at 1 o'clock in the morning, and you are happy. So the next day you open up myprog.c, and you realize that Func1, it's not exactly what you wanted. So you delete that, and as you are now well into the habit, you check in again. Then you get inspired and add Func3, and of course, check that in. After a bit of a reflection, you think maybe I could combine some of the functionality of Func3 into Func2.

So you open up myprog.c, and again, start editing. Midway through that process, you say to yourself-- and this is the important part after saving myprog.c back to the disk, wiping out the previous version--oops, I guess that isn't going to work. Now in the days before your use of Version Control, you start sweating and wondering where you made a backup copy? Was it in that best-best final with bug fixes directory or in the best-best ship it directory? And you try to figure out how you could recover your work. But now that you've got Version Control on your side, you simply revert myprog.c back to the latest version of your repository, and you're ready to move forward again in moments, hero mode on. Now let's go see that on the command line.

So once again we find ourselves here at the command line. As before, we're inside our fsvc1 directory where our source code is there is our myprog.c. So let's open up myprog.c and delete Func1. Now we can run the git diff command and see what's the difference between what's in our working set and what's in the repository. Now in this case, we only have one file, so it's very easy in more sophisticated situations.

You probably want to be able to specify either the file that you're working on or a subset of the directory; otherwise, you may end up with pages and pages and pages of this output. So we can see that the Func1 code has a minus sign at the beginning and is in red, indicating that the code was deleted. So let's check in this change, and then as you're beginning to trust Version Control, there is no need to look at the log at this point, so let's just go ahead and add Func3.

So once again we'll come back and edit this, save it, and I will check that in. All right, and then we can run git log --oneline --all, see all of our changes, so we can see we've--if we read from the bottom--we added it. We added Func1, we added Func2, we deleted Func1, we added Func3.

Now, we see our full list of commits. So now that we have all the numbers, we can run the git diff command between our check in number 3 Add Func2 and our most recent Add Func3. So we say git diff and the number there, 7555e83 and 4b8ed72, and you can see that it shows between those two different diversions we removed Func1, and we added Func3.

So now let's once again edit myprog.c and come down here and delete Func3, and then we're actually going to save it, and you can see myprog.c no longer has Func3 in it, and we realize we didn't really want to do that. So in order to figure out exactly which version we want to restore--and in this case, we know it's the most recent one--in Git we can say git diff HEAD, and it shows us that the difference between the repository and the working set is that the working set has Func3 removed.

So what we want to do is restore our working set to the latest state, to what was in the repository. So now we say git checkout myprog.c, and then if we type it out again, you can see Func3 is back in its full glory. And then we can see what the Version Control system thinks again, by typing git diff HEAD, and you can see that there is no difference between the working set now and the repository.

And one other way--as we just ran git diff and saw that we didn't have any differences between our working set and our repository-- another way to verify the repository is up to date with your working set is to say git status, and again, it will show nothing to commit. Now at this point, we're going to take this entire directory, including all the git hidden directory. Remember, we have this .git hidden directory, and if we just go take a quick look in there, there is a whole bunch of additional directories and files that keep track of all the versioning information, this is the repository information.

For this particular thing, we're going to zip this entire thing and put it into the Exercise Files directory. If you then take that and unzip it in any directory that you want, and you come back to this top level, you can then say git log --oneline -all, and see the same thing that we just did here step by step in the course, and you can experiment with this particular repository to your heart's content, adding additional things, doing additional commits, practicing doing reverts in an environment where you know you have a repository that has some known working states that's compact enough to really understand, as opposed to somebody handing you a repository of 25 or 150 files with 200 commits already made.

So next up, we'll look at a short history of Version Control and review the specific terminology that applies to all Version Control systems we'll be using in this course.

Demo two: Handling the "oops"
Video duration: 6m 2s 2h 55m Intermediate

Viewers:

Demo two: Handling the "oops" provides you with in-depth training on Developer. Taught by Michael Lehman as part of the Fundamentals of Software Version Control

Subject:
Developer
Software:
Git Mercurial ALM/TFS Perforce
Author:
please wait ...