New terms from treehouse – Git Basics Part 1 – Why Version Control Matters, Getting Started with Git, and Branches

Why Version Control Matters

Introduction to Git Basics

VCS means version control system, and lets a developers work in the same code base together without stepping on each others’ codes.

Life without Version Control

Cowboy coders – coders who don’t follow best practices.

If you write a feature, decide you don’t want it and delete it, but then then decide you want it later, it helps to have a version of each time you saved on hand, with a description so you can pull up what you need. Even then, if you were working on this with another person, it’d be hard to compare your code and changes.

How Version Control Works

It’s called a VCS because it let’s you control all the versions of what you’re working on. Revision Control or Source Control mean the same thing. A repository is a collection of all the different versions of a project. It includes the the order the changes occurred in, a description of each change, and who was responsible for each change. Each project will have its own.

It wouldn’t make sense to treat unfinished work as a version. The VCS doesn’t know when a change has occurred, you have to tell it, which is called committing.  Versions are often referred to as commits. Doing this manually is messy, and the VCS tries to hide this from you by storing the files in special hidden folders.

To explore your changes, it will give you a set of tools to explore your revision history. Like being able to view and filter the list of commits, or what version is displaying. They also allow you to share your repositories with other to work on things together.

Why Git?

Inventor of Linux made this as well. Linux is a huge project, and Git was designed to help with collaboration on that. Git is a distributed VCS. Some VCS are centralized, meaning that the repository sits on one server. You can’t access it without a network connection, and it can be easily lost if the server is destroyed. For distributed ones, there is no central repository, everyone who works on a project has their own.

Originally Git was going to be a set of tools and commands (plumbing) for you to build your own VCS (porcelain), but eventually it evolved into one itself. It still has the internal tools and commands though, which give you a lot of power.

Github is the most popular site for sharing your repositories.

Getting Started with Git

Working with Git Repositories

Creating and working with repositories is a simple process in git. First, we’ll check to see if git is installed using the –version flag.

Screen Shot 2014-11-03 at 4.17.10 PM

To create a repository, type git, then init, then the name you want to give it. This will give you a success message saying where it’s been created.

Screen Shot 2014-11-03 at 4.18.33 PMScreen Shot 2014-11-03 at 4.20.39 PM

Screen Shot 2014-11-03 at 4.21.42 PM

Looking inside it, there’s nothing there. It’s not just an empty directory though, remember it puts a lot of stuff in hidden files and folders. With -a we can see those, including the .git directory, which will contain all the info on our project eventually.

Let’s say you made a directory with a bunch of files before making the repository.

Screen Shot 2014-11-03 at 4.24.24 PM

Just run git init without giving it a project name. Since you didn’t give it a folder name, it will assume you want a new repository for this folder.

Screen Shot 2014-11-03 at 4.25.52 PM

Note that the name of the repository is not essential, so long as the .git folder exists within it.

Screen Shot 2014-11-03 at 4.28.07 PM

The .git is the only thing that matters, you could actually delete everything else in that folder and still restore your work. To remove the repository, you’d just delete the .git folder.

Screen Shot 2014-11-03 at 4.29.19 PM

Committing Changes

We’ll start by making a repository, going into it, then creating a read me file with nano.

Screen Shot 2014-11-04 at 2.03.44 PM

We’ll then add some text, and save it. We’ve now created a new file in our repository.

Screen Shot 2014-11-04 at 2.05.36 PM

Before we can commit it, we need to add the file to the repository, letting git know the file is important and that its changes should be tracked there. We do this with the git add command. You have to do this manually as there may be some files you don’t want to add or track.

Screen Shot 2014-11-04 at 2.07.10 PM

Next we use the git commit command to commit our changes.

Screen Shot 2014-11-04 at 2.09.05 PM

Lines starting with # are comments. It tells us some info like the committer, what branch we’re on, and what we changed, in this case, we added a new file README. We’ll add our description at the top, which should be short and meaningful. Save and exit nano.

Screen Shot 2014-11-04 at 2.11.29 PM

You get a success message, and info on your name and email. It’s important to know who did what, in case someone needs to get in touch with you. If it’s not listed, it will try to guess based off your username. To change them, we’ll use the —global flag to let them know we want to change this for all of our repositories.

Screen Shot 2014-11-04 at 2.16.09 PM

Now that the file is in the repository, let’s go back and edit it a bit.

Screen Shot 2014-11-04 at 2.17.35 PM

So we’ve made a change, should we commit it? Good rule of thumb: if there is a good commit message you should use, then you should. You should commit when there is good reason to, the more often you do, the better your version history will be. We’ll use git commit again, this time with the -a flag, for all, which means to commit all the changes it can find. The -m stands for message, and let’s us add the commit message from the command line without having to go into nano.

Screen Shot 2014-11-04 at 2.21.14 PM

It’s better to err on committing more often than not.

The Staging Area

The staging area let’s you control what you want to include in the commit. The git status command shows the current version control status of the project. It tells us what branch we’re on, and that there aren’t any changes to commit, as nothing has changed.

Screen Shot 2014-11-04 at 2.25.48 PM

Right now we just have the README, let’s add some more files and rerun git status.

Screen Shot 2014-11-04 at 2.27.55 PM

It tells us we have three untracked files, and you can see it tells us we need to add them to the repository before they can be tracked.

Screen Shot 2014-11-04 at 2.29.11 PM

File1 has been moved to the “changes to be committed” section, which is known as the staging area. If we add the other two files to the repository, they’ll be there as well.

Screen Shot 2014-11-04 at 2.30.35 PM

We can then add them like before.

Screen Shot 2014-11-04 at 2.31.23 PM

Now, we’re back to the original status of nothing to commit.

Screen Shot 2014-11-04 at 2.31.59 PM

Let’s change file1 and 2 with nano. You can see they’re listed under “changes not staged for commit”. Git knows the files are in the repository and it needs to track them, but they’re not in the staging area.

Screen Shot 2014-11-04 at 2.33.48 PM

Let’s just add and commit file1, using the git add and commit commands.

Screen Shot 2014-11-04 at 2.37.00 PM

If we rerun git status, we can see file2 is still there. We can add it the same way.

Screen Shot 2014-11-04 at 2.37.47 PM

Looking Back on what We’ve Done

How do we review the commits we’ve saved to the repository? The git log command shows us a log of all the commits, starting with the most recent. Each entry includes a unique commit identifier, aka a hash. You can see the author and date of the commit as well, and the commit message.

Screen Shot 2014-11-04 at 2.42.36 PM

To see the details of a specific commit, use the git checkout command, which uses the git identifier. It doesn’t need the whole thing, just enough so it knows which one you’re referring to, usually the first 5-6 characters.

Screen Shot 2014-11-04 at 2.48.08 PM

The detached head state warning just lets you know that you’ve pulled up an older version of your code, and if you try to make any changes things could get weird.

If you ls, things will look like they did before, but if you cat file1 and file2 you can see they’re empty here.

Screen Shot 2014-11-04 at 2.49.59 PM

So how do you get back to where we were before, to the present state? Use git checkout, then master.

Screen Shot 2014-11-04 at 2.51.03 PM

The get diff command lets you see what’s changed between two versions of a project. It takes two arguments, the id of the first commit, and the id of the second.

Screen Shot 2014-11-04 at 2.52.35 PM

You can see the only difference is that “This is file2” was added to file2.


Branches are like alternate realities for your project, they let you pursue different course courses of action for your project in parallel.

Beginning to Branch

Master is the default branch in any git repository, and is usually the canonical version of your project, meaning the one that’s deployed in production. This is optional of course, but is the typical convention.

Screen Shot 2014-11-04 at 3.25.44 PM

To make a new branch, use the git branch command, and give it a name, which should be short and meaningful.

Screen Shot 2014-11-04 at 3.27.54 PM

We made it, but we’re still on the master branch. To switch, use the git checkout command again, which makes sense because a branch is just another version of our code. By default it will take you to the latest commit for that branch, aka the head commit.

Screen Shot 2014-11-04 at 3.29.13 PM

Screen Shot 2014-11-04 at 3.30.11 PM

Let’s change and commit file3 here.

Screen Shot 2014-11-04 at 3.31.39 PM

We can see this commit is at the top of our git log now for this branch.

Screen Shot 2014-11-04 at 3.32.46 PM

If we were to switch back to the master branch with git checkout master, then check its git log, this commit would not be there, only in its branch.

You can create a new branch and switch to it at the same time by adding the -b flag to the git checkout command. Now, while in the foo_feature branch, let’s do this. Since we created it off that branch, and not master, the file3 commit is here as well. When you make a branch, it copies whatever branch you were on at that time.

Screen Shot 2014-11-04 at 3.36.37 PM

Managing Branches

The git branch command will list all the branches, with the one you’re in at the moment starred.

Screen Shot 2014-11-04 at 3.41.31 PM

To delete a branch, use the -D option with the git branch command, followed by the name of the branch. NOTE: You can’t delete a branch you’re currently in.

Screen Shot 2014-11-04 at 3.43.03 PM