Start learning with our library of video tutorials taught by experts. Get started

Fundamentals of Software Version Control
Watching:

Demo one: Getting started


From:

Fundamentals of Software Version Control

with Michael Lehman

Video: 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.
Expand all | Collapse all
  1. 2m 12s
    1. Welcome
      56s
    2. What you should know before taking this course
      23s
    3. Using the exercise files
      53s
  2. 25m 8s
    1. Overview of software version control
      2m 51s
    2. Understanding version control concepts
      5m 14s
    3. Demo one: Getting started
      11m 1s
    4. Demo two: Handling the "oops"
      6m 2s
  3. 11m 3s
    1. The history of version control
      3m 44s
    2. Terminology
      4m 27s
    3. Exploring centralized vs. distributed systems
      2m 52s
  4. 28m 42s
    1. Getting files in and out of a repository
      4m 38s
    2. Saving changes and tracking history
      2m 47s
    3. Reverting to a prior version
      1m 42s
    4. Creating tags and labels
      1m 5s
    5. Branching and merging
      4m 10s
    6. Exploring workflow integration and continuous builds
      2m 46s
    7. Using graphical user interface (GUI) tools
      2m 39s
    8. Integrating a version control system with an integrated development environment (IDE)
      2m 50s
    9. Examining shell integration
      3m 26s
    10. Looking at forward and reverse integration
      2m 39s
  5. 25m 59s
    1. Installation and setup
      3m 31s
    2. Creating a repository and a project
      5m 10s
    3. Working with check-in, checkout, and revert
      6m 12s
    4. Tagging
      1m 34s
    5. Branching and merging
      5m 32s
    6. Working with GUI clients and IDE integration
      4m 0s
  6. 16m 13s
    1. Installation and setup
      55s
    2. Working with check-in, checkout, and revert
      9m 34s
    3. Tagging
      1m 7s
    4. Branching and merging
      4m 37s
  7. 26m 41s
    1. Installation and setup
      3m 47s
    2. Creating a repository and a project
      6m 15s
    3. Working with check-in, checkout, and revert
      8m 31s
    4. Tracking history and tagging
      2m 15s
    5. Branching and merging
      5m 53s
  8. 19m 25s
    1. Installation and setup
      3m 1s
    2. Creating a repository and a project
      1m 6s
    3. Working with check-in, checkout, and revert
      6m 39s
    4. Tagging
      2m 13s
    5. Branching and merging
      3m 44s
    6. Working with GUI clients and IDE integration
      2m 42s
  9. 16m 54s
    1. Installation and setup
      1m 48s
    2. Creating a repository and a project
      59s
    3. Working with check-in, checkout, revert, and tracking history
      6m 9s
    4. Tagging
      1m 50s
    5. Branching and merging
      4m 29s
    6. Exploring GUI and shell integration
      1m 39s
  10. 3m 38s
    1. Selecting a software version control that is right for you
      2m 30s
    2. Next steps
      1m 8s

Watch this entire course now—plus get access to every course in the library. Each course includes high-quality videos taught by expert instructors.

Become a member
Please wait...
Fundamentals of Software Version Control
2h 55m Intermediate Nov 07, 2012

Viewers: in countries Watching now:

This course is a gateway to learning software version control (SVC), process management, and collaboration techniques. Author Michael Lehman reviews the history of version control and demonstrates the fundamental concepts: check-in/checkout, forking, merging, commits, and distribution. The choice of an SVC system is critical to effectively managing and versioning the assets in a software development project (from source code, images, and compiled binaries to installation packages), so the course also surveys the solutions available. Michael examines Git, Perforce, Subversion, Mercurial, and Microsoft Team Foundation Server (TFS) in particular, describing the appropriate use, features, benefits, and optimal group size for each one.

Topics include:
  • 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
Subjects:
Developer Mobile Apps Desktop Apps Programming Foundations
Software:
Git Mercurial ALM/TFS Perforce
Author:
Michael Lehman

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.

There are currently no FAQs about Fundamentals of Software Version Control.

Share a link to this course
Please wait... Please wait...
Upgrade to get access to exercise files.

Exercise files video

How to use exercise files.

Learn by watching, listening, and doing, Exercise files are the same files the author uses in the course, so you can download them and follow along Premium memberships include access to all exercise files in the library.
Upgrade now


Exercise files

Exercise files video

How to use exercise files.

For additional information on downloading and using exercise files, watch our instructional video or read the instructions in the FAQ.

This course includes free exercise files, so you can practice while you watch the course. To access all the exercise files in our library, become a Premium Member.

join now

Are you sure you want to mark all the videos in this course as unwatched?

This will not affect your course history, your reports, or your certificates of completion for this course.


Mark all as unwatched Cancel

Congratulations

You have completed Fundamentals of Software Version Control.

Return to your organization's learning portal to continue training, or close this page.


OK
Become a member to add this course to a playlist

Join today and get unlimited access to the entire library of video courses—and create as many playlists as you like.

Get started

Already a member?

Become a member to like this course.

Join today and get unlimited access to the entire library of video courses.

Get started

Already a member?

Exercise files

Learn by watching, listening, and doing! Exercise files are the same files the author uses in the course, so you can download them and follow along. Exercise files are available with all Premium memberships. Learn more

Get started

Already a Premium member?

Exercise files video

How to use exercise files.

Ask a question

Thanks for contacting us.
You’ll hear from our Customer Service team within 24 hours.

Please enter the text shown below:

The classic layout automatically defaults to the latest Flash Player.

To choose a different player, hold the cursor over your name at the top right of any lynda.com page and choose Site preferencesfrom the dropdown menu.

Continue to classic layout Stay on new layout
Welcome to the redesigned course page.

We’ve moved some things around, and now you can



Exercise files

Access exercise files from a button right under the course name.

Mark videos as unwatched

Remove icons showing you already watched videos if you want to start over.

Control your viewing experience

Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.

Interactive transcripts

Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.

Thanks for signing up.

We’ll send you a confirmation email shortly.


Sign up and receive emails about lynda.com and our online training library:

Here’s our privacy policy with more details about how we handle your information.

Keep up with news, tips, and latest courses with emails from lynda.com.

Sign up and receive emails about lynda.com and our online training library:

Here’s our privacy policy with more details about how we handle your information.

   
submit Lightbox submit clicked