Welcome back to Introduction to Continuous Integration. I'm Ben Lambert, and I'll be your instructor for this lecture.

In this lecture, we're going to talk about Version Control Systems, also called source control and revision control.
I'm going to try to just stick with version control throughout the lecture, however, if I slip up and call it source control, you'll know that I'm talking about the same thing.

By the end of the lecture, you'll know what version control is, and you'll be able to recognize a few of the commands used by Git, a popular Version Control System.

So, what is version control and why should you care? On an abstract level, version control is about tracking changes to something over its lifetime. In the context of software development, version control is about tracking changes to one or more files over time. The term file here could represent just about any type of file. It doesn't have to be just source code files. Often times you'll see things like documentation, configuration files, and even images under version control.

Version control allows developers to collaborate on a single project and track its history. Every change made by a developer is saved and can be accessed later, and everyone can work on the same code base and see the complete history for all of the files.

Now, that's admittedly a simplistic take on version control. However, conceptually, it is pretty simple. It's not until we get into patterns of usage where we start to get complicated. We're not going to get into that level of detail in this course. However, likely in future courses we'll cover things like Trunk Based Development and Git flow. Now, if that was Greek to you, that's fine. It's not going to hinder you from taking this course. Just know that we'll get into more depth in future courses.

There are different types of Version Control Systems, and for each type, there are different tools. I'm going to talk mostly about Distributed Version Control Systems, and in particular, I'm going to talk about Git. Now the reason I'll talk about Git is because it's very widely used these days, and it makes it worthwhile to know.

Like I mentioned, there are different types of Version Control Systems. We started out many years ago with Local Version Control. Anyone who wanted to make changes to code needed to connect into the server where the code lived and edit it there, and then they could save their changes into the Version Control System that was on that server. Now for the most part, version control like this, Local Version Control, isn't used today. Outside of, maybe, incorporating into a product such as a wiki.

Eventually, we moved on to a client-server model, which is also called a centralized model, and this is where code lives on a master server someplace and developers check it out onto their computer. Then they can make changes and check it back in. Picture this as kind of like a library. Tools such as SVN and Team Foundation Version Control are an example of Centralized Version Control. Now this is still widely used today. This model allows the server to be configured to allow only specific users to access source code, and it allows for some pretty granular access control, which can be especially useful for auditing and compliance reasons.

And we also have Distributed Version Control Systems, as I mentioned before. With the client-server model, if you wanted to see a specific version of a file, you'd use some client tool to request it, and the server would send it to you assuming you have access to it. The distributed model is a bit different. With distributed, you have the full history of the project locally. Once you've cloned a repository, you have access to everything. And in this model, there doesn't need to be one central version of the code base. For example, you could push changes from your environment to your coworker, and they could push changes back to you.

Now that's not a typical use case, but it is possible because of the flexibility of Distributed Version Control Systems. A typical use case is to have a central server that contains what is considered to be the canonical source, and used in this way, it's kind of like the centralized model. Tools like Git and Mercurial are examples of Distributed Version Control Systems.

Alright, let's take a look at actually using Git and GitHub for version control. GitHub is a popular hosted version of Git that allows free public code repos, and it doesn't require a credit card to sign up.

So, to start, I'm going to create a repository using the GitHub interface, and I'm going to name it git_demo_app. Now, I'm going to leave this window alone for now, but I'm going to come back to it later. I'm gonna start by verifying that Git is installed, and I can do this with the git command and passing in the --version parameter.

It should return the version of Git. As you see here, it returns that I have 2.7.4 installed. Now if it doesn't return this for you, it's possible that you have a different version installed, or if it's an error, it's because maybe you don't have Git installed.

Now it's time to create a local project. I'm going to use Atom, my text editor of choice, and I'm going to create a simple hello.world app in Python. Now that I have some code, I need to initialize a Git repo so I can start tracking changes, and I can do this with the git init command.

Now, I need to tell Git which files to track. For this, I can use the git add command. Okay, so far, what we've done is to create a local Git repo, and add the file hello.py to be tracked. Next, we need to actually commit, which tells Git to save a copy of the hello.py as it is right now. For this, we use the git commit command with the -m flag, to add a commit message. At this point, our local repository has a copy of hello.py as it is right now. However, it's only local. We need to tell our local repo how to talk to GitHub. For this, we use the git remote command to add the GitHub remote URL.

Now that our repo knows how to talk to GitHub, we can send the code to GitHub with the git push command. Okay, let's look at actually changing the file. I'm going to go back to my text editor, and I'm going to change the text to say, Hello Git, and save it. Now, at this point we can use the git status command to see what we have changed. It should show that our hello.py file has changed, and we can see how it's changed with the git diff command. Okay, let's commit this change.

If we look through our commit history now with the git log command, we can see all of the changes that we've made. The git log command has a lot of options, including a lot of formatting options. Now let's see how to create a new branch and make changes to it. Branches have a lot of uses, one being able to create local branches that allow you to have new features developed in a separate branch, and then merge it back into our main line later.

By using the git branch command, we can see a list of existing branches. The one with the asterisk beside it is the one that we're currently using. Okay. We use the git checkout command with the -b flag to create and check out a new branch, and we can verify that this worked with the git branch command again. Now, I'm going to make a few changes to our hello.py file and commit them. Let's switch back to our master branch and see what happens.

In looking at our hello.py file, it shows that we don't have the changes that I just made, and that's because we made them on a different branch. So, if we're happy with those changes, we can merge those changes from our feature branch back to our master branch with the git merge command. Now, if we look back at hello.py, we'll see those changes from our feature branch now exist on the main branch.

At this point, I don't need that feature branch hanging around anymore, so I can delete it with the -d flag of the git branch command. Now I can push these changes up to GitHub, and we'll be able to see them in GitHub. So let's go back to GitHub, reload the page, and see what happens. So now we can see that our app is here, and then we can see the history of all the changes that we've made. This is the same thing we saw on the command line.

And that's basically Git and GitHub at a very high level. In our next lecture, we're going to talk about testing, and what kind of testing needs to happen for Continuous Integration. Alright, let's get started.