In this course we will be using “version control”. We’ll achieve this via our cart263 Git repository to store all our coursework. So what is version control? What is Git? What is a repository? What is GitHub Desktop for? How do we actually use all this stuff? And why should we?
For many tasks, just having a file that you edit and save repeatedly over time is completely fine. Maybe it’s an essay for a course, maybe it’s a list of all your games, maybe it’s something else.
But most of us have had a situation in which we want to keep a series of versions of a file. Mostly it’s because if we screw up, we can more easily go back to a version that was still good. Maybe we’re working on a complicated image in PhotoShop and we end up with a series of files called cool-pic-1.psd, cool-pic-2.psd, cool-pic-2b.psd, cool-pic-3.psd, and so on. The set of files end up as a kind of history of the final file.
With programming, this idea of keeping track of the history of a coding project over time is very, very important. It’s called version control. In part, it’s important because it’s good to be able to undo things by going back in history. But it’s also important because it’s good to be able to see that history to understand the project. It’s especially useful if you’re working with other people.
Git and other version control software is so popular and so important in the programming world that it is essential that you understand how it works and how to use it. It will be part of getting a job later, as well as making your life better forever.
Git is software that helps to automatically keep track of the history of versions of our files. For any project, we create a Git repository (often called a “repo”) which is like a folder that tracks the history of everything that happens in it. We will use GitHub Desktop to manage our repository easily.
In order to use Git we need to change the way we work a little bit. As well as having our set of files for a project (like the HTML, CSS, JavaScript, images, etc.) and saving them each time we make changes, we need to add an extra layer.
First, we must always do our work inside the repository folder on our computer. We have a folder called cart263 and we will do all our work in that folder. If you’re starting a new project, for example, you would make a new folder inside cart263 called something like projects and then a folder inside that for the specific project called something like project1.
For now, we will focus on the file that should already be in your cart263 from when you created it called README.md. (If it doesn’t exist for some reason, please create a new file with that name in VS Code and save it into your cart263 folder.)
By default, this file has placeholder text in it that is not very informative. Let’s edit the file and use this to show Git at work.
README.md file in your cart263 repository folder in VS Code. (You can do this by selecting File > Open... in VS Code and finding the file, you can probably right click on the file and choose to open it with VS Code, you can probably drag the file onto the VS Code icon at the bottom of your screen.)Let’s imagine the changes that we made are worth not just saving but also keeping specific track of in our repository.
To see that GitHub Desktop has noticed the changes we made, we need to run it and look at the interface.
cart263 repository it should show by default. (If it isn’t selected, click the button at the top right where it says “Current Repository” and select your cart263 repository from the list.)README.md. If you select the file, you’ll the specific changes displayed on the right side of the application.When we want to add changes to our repository it is called a commit. We’re saying we want to commit to these changes because we’re sure we want them in our project. Importantly, when we commit, we also write a message that describes our changes precisely.
Let’s say we’re happy with the changes we made to README.md. (If not, go back to VS Code and change it more, then save it again and come back to GitHub Desktop.)
README.md. (Something like: “Initialized README to contain course code and title”)The changes are committed along with your message! The new version of README.md with your changes is now part of the repository on your computer and you will see there are now no changes displayed by GitHub Desktop.
To prove to yourself that the changes and the message are really there, go to the “History” tab next to the “Changes” tab. You will see a list of the commit history of your cart263 repository. Right now it is probably small, but it will get very long. The most recent commit is at the top, and it should have the message you just wrote.
If you select the commit in the history, you can also see a list of the files that were changed and the changes that were made to them.
Let’s imagine that README.md is part of some larger project and we want to keep working on it. We would follow this same process of making some changes and then, when a set of related changes have been made, commit them.
README.md file and save itIf you want to, look at the History again to see your two separate commits are listed there.
Currently the repository on your computer is up to date, but the version of your repository that lives on GitHub.com is not. We always want these two versions of the repository to be in synch to avoid trouble. To update the GitHub.com repository (called the remote repository) we need to push the changes we’ve made to it (it’s just like uploading them).
After a hopefully short time, your changes (the commits) will have been uploaded to GitHub.com. This is great because they are safe there now (“in the cloud”). If you were to accidentally delete the cart263 folder (repository) on your computer, it would be fine because you could get all your files back from GitHub.com!
Any time you add a new file to your repository folder or remove a file from the repository, this counts as a change. To try it out let’s add a file.
File > New FileFile > Save and give it a name (doesn’t matter what) and make sure to save it inside the cart263 folderNow let’s delete the file we just created.
cart263 folder on your computer, move the new file to the Trash or Recycle Bin, or just somewhere outside your cart263 folderNotice that your History in GitHub Desktop now includes at least two commits from editing README.md, one commit for adding the new file, and another commit for removing it. Even though adding and then removing the file leaves the repository exactly the way it was, it’s still part of the commit history.
Although we’ve only been editing a single file (README.md) or adding and removing a single file each commit and push, normally you would end up editing/adding/removing multiple files in a single block of work and then committing all those changes at once.
We will talk more about “when to commit” once we get to actual code, but the basic rule of thumb is to commit your changes when they represent a meaningful unit of work.
This is the new working approach in this course. Instead of just “edit, save, edit, save” as with ordinary software, we add “commit, push, commit, push, commit, commit, push” to the cycle.
README.md in this tutorial) in VS CodeThis will take some getting used to, but that’s pretty much all there is to it. Another tutorial we cover these ideas again in the specific context of code!