Git Version Control Part 2 and getting comfortable with the command line

In the last few blog posts, I have started to describe how and why we are using git to manage our code, and in Part 1 I introduced the first critical concepts that we need to know when using git; commits, branches, and checkouts.
Then in the last post, I started to explain why we are learning git before we actually start to learn coding. Today we are going to dive a little bit deeper into these topics and understand the process creating our first git repository and our first commit. But before we do that, it is going to require us to learn another new skill, the command line.
There are many graphical git editors out there, but if you want to be a software engineer you are going to have to understand how to use the command line. Thus now seems like a good time to start introducing this topic.
The command line could be a whole course by itself, so for now I’m just going to give a quick overview, and then we can expand on this topic in the future.
I currently work on a Mac so this post will be structured around OSX, but the same commands will work on Linux as well. Windows is a bit of a different story and we will have to tackle that in the future.
To open the command line terminal for the first time, you will need to open your Applications folder in Finder then navigate to Utilities -> Terminal.app. This will open a window that looks something like the window below.

When we open a terminal window, we “living” in the home directory, which is our working directory. In the case of my computer, this is /Users/pfarrell which is the folder where all the files and programs for my personal account live on my computers file system.
To show this for yourself, click inside this window and type “pwd” which stands for “print working directory.” Your result will be different based on the username you have setup for your computer but the concept is the same.

So next we want to create a new folder were we are going to store our git repositories, and then create another folder to house our first tutorial repository. I’m going to call this folder projects.
The command to create a new folder is “mkdir” so we want to run the following command to create this new folder called “projects.” Then we want to move our working directory to this folder; you do this with the “cd” command which is “change directory.” After we change the directory, you can type “pwd” again to see you new working directory.

I now need to create another new folder that is going to be the repository where our code sits; I’m going to call this folder “tutorial_1” and then change my working directory into this folder.

Success! Now we are ready to actually start working with some git commands. Some of you may run into some issues here because git might not actually be installed on your computer by default, please comment below if when you run these commands you get an error. But I’m going to assume for now that git is installed and write a future post about how to install it.
To turn our working directory into a git repository where we can store and manage our tutorial 1 files with version control, we will now run the command “git init” which initializes a git repository.

So what happens now? Well we can start actually creating files in the working directory and then create commits to the track those files and any future changes to them. Let’s start with a simple one line file called hello.txt; you can use the following command to create the file.

So now let’s actually create the commit to track that file. I now I need to introduce another new concept which are unstaged, staged, and commited changes, which we are going to think of as three separate boxes for arguments sake.
When you first make an edit to a file using a text editor or the command I ran above to create hello.txt, those changes are unstaged; meaning that git is not really protecting them and they are kind of just working changes. They live in the unstaged changes box for now.
But once we are ready for those change to turn into a commit, we have to do what is called staging. For the sake of making this easier to understand, is taking those unstaged changes out of one box, and putting them in the staged changes box.
To move the changes from one box to another, we run the “git add” command as shown here.

Now that the changes are in this new staged changes box, we can actually use that box to create our first commit. To create a commit, we need to give it a message as well, so the command to create this commit is show here and give it a message is shown here. “-m” is the argument to the command that says what comes next in quotes is the message for this commit.

Okay, so now we have created our first commit! This means that the new file called hello.txt containing the words “Hello Brooklyn” will forever be in the history of this git repository, and these changes now live in the “commited” box.
Remember we also talked about branches in the part 1 blog post? Well by default git created a branch for us called master which is the branch we are currently working on and pointed to. If you want to confirm this, you can run the command “git branch”

And now, how do we actually see the commit we just created and confirm that it is there? We use the command “git log” which shows us the contents of our “commited” box.

So where are we now? I think it is about time to end this post since I don’t want to introduce too many concepts all at once, but we have now learned a little bit about the command line, created our first git repository, our first commit.
In tomorrows post, we are going to create our second commit to track new changes and actually send these changes up to GitHub to be hosted as an open source project that will be available to the world, and to you as the reader. Let me know what you thought of this post in the comments and see you tomorrow.