Version Control

Version Control - continuously backing up your code because you are afraid that you or someone else is going to mess that code up

Without VC:

I type a blog post (C1), and then later on modify the blog post (call this modified post C2). I then save this blog post. I lose the original C1, and instead replace it with C2.

I’m so excited with my new blog post that I modify the blog post again (C3) with a button to allow people to tweet my post, and then again (C4) with a twitter feed. After that, the excitment wears off and I leave the blog to rot.

Two months later, I realize that nobody is reading my blog. I travel to the website myself to find that even I can’t read my own blog either. Somehow, I have introduced a fairly minor “bug” while introducing all these awesome features that prevents people from reading text.

No, I don’t know where this bug is. And I won’t be able to know exactly when I introduced that bug. So I’m stuck. And I won’t be able to restore C1, the original that I know would work, because I had already deleted it. My blog is ruined, and I have to start all over again.

With VC:

I type up a blog post (C1), and then upload over to a Virtual Control System for safe-keeping. The Virtual Control System is essentially a service that stores all different versions of the same file in one easy-to-access location. So I never have to worry about losing C1, because the Virtual Control System will keep it for me.

I then continued modifying my blog post, and each time I do so, I upload my changes to the Virtual Control System. The VCS soon has a copy of C1, C2, C3, and C4 (the final update of my blog post).

Two months later, I found out nobody can read the text of my blog due to a “bug”, and this time, I now have options. First, I can look at C1, C2, C3, and C4 individually and search for clues for where the bug is. Second, I could restore from an earlier version of the blog (C3 instead of C4) and see if that would resolve the issue. If it does resolve the issue, then I know C3 is the problem, and I can start searching for problems there.

Finally, I can always do a hard-reset of the blog back to the original C1, which I know works, and then slowly add in new features until I see the “bug” again, and then start to fix it.

Without Version Control, you are doomed whenever you make a single mistake. With Version Control, you still have the copies of all your previous work, and you may still be able to fix your mistakes.

Using Git

Git is a popular Version Control System used by many developers. This program keep tracks of all changes you made to the file and saves it over to a git file. Then anyone can look at the “history” of my git file to find all my past versions of my project. So, in my blog example, I can easily see C1, C2, C3, and C4 by accessing the git file.

However, using a Version Control System only on my own computer is not enough. What happens if my own computer dies? Then I lose everything I saved on there. Luckily, there are multiple web sites that can host your git file and store every change you made. The most popular of these sites is “GitHub”. So, in case a computer dies, I can get a new computer, go online and then redownload my file from “GitHub”.

Of course, I could just save my git file onto a USB, and then keep that USB safe. Doing that however makes it hard for other people to help me improve my blog post, because they would need the USB to modify my file. Uploading my file to “GitHub” would allow other people to easily access my file and then suggest changes to me. These suggestions are known as “pull requests”. If I like the “pull requests”, I’ll acccept them and adapt them into my blog post.

The Merits of Command Prompts

While it is easy to download programs to help you manage Git, programmers prefer using Git by typing in commands into a command prompt. The command prompt is essentially a black screen where you type in a command (such as “cd C:\Programs” to access the Programs folder on your computer) to do stuff. Programmers like using command prompts because it is quicker to type in a “command” than it is to “click” on a button in a program. However, in order to use the command prompt, you have to actually know what commands to type. Buttons tend to have images and text to help you understand what will happen if you click on it, but to understand the command prompt, you have to read a long and boring manual…and the only way to get that manual is to type in a command in the command prompt.

Programmers want to complete jobs as quickly as possible, so they are willing to accept the inconvenience of memorizing commands to get the advantage of speed. If you want to delete 10 files, it’s much quicker to type out “rm [filename]” 10 times than it is to click on the delete button 10 times.

Note: This blog post was originally posted on 04/07/2015, and then last updated on 04/17/2015.