Beginner Project: Basic Git

Getting to Know Git

This project will walk you through getting to know Git and Github by walking through...

1. Creating a project on your computer
2. Stage and committing files
3. Branching your project and merging branches
4. Revert changes that you made to your project

Note: When the guide refers to executing a command, it means to do so in the command line. On a Mac, you'll want to use Terminal or iTerm 2. On Windows, you should be using the Git Bash program that's installed if you follow these instructions.

---

Vocabulary

Some terms to be aware of while reading through these instructions

Directory

• A folder on your computer

Home folder

• The folder on your computer that most of your personal files are kept in
• On OS X, this folder can be found at /Users/{username}
• On Windows, this folder can be found at C:\Users\{username}

---

Steps

1. Creating a New Project

The first thing that we'll want to do is create a new project to be tracked by Git. To start off, open your command line program and enter the following commands:

mkdir projects
cd projects
mkdir git-beginner-project
cd git-beginner-project

What this does is create a new folder called projects inside your home folder, step inside of it using the cd command, then do the same with the git-beginner-project folder.

Now that we have a place to create your project, we want Git to set itself up to track the files inside this folder. To do that, we run the following command:

git init .

This tells Git to init, or initialize, a new project inside the current directory (which is refered to by a .).

If you see a message like this:

Initialized empty Git repository in c:/Users/alex/projects/.git/

Then you're all set!

2. Staging and Committing Files

Next, we'll add some files to the project and see how Git can keep track of them. In the command line, type the following command

touch hello.txt

This will go and create a new file called hello.txt. Now, run the following command to see what changes Git is currently detecting:

git status

Let's take a look at the output and break it all down:

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

       hello.txt

nothing add to commit but untracked files (use "git add" to track)

This means that git sees no changes to files that it is already keeping track of, but does see a new file that it doesn't recognize. In Git, a "tracked" file is one that Git is currently watching for changes, and an "untracked" on is a file that it knows nothing about yet.

We want to get Git to start keeping track of our file. Do to that, run the following two commands: the first will add the file to those that Git keeps track of, and the second will output the status again

git add hello.txt
git status

Which should result in something like this:

$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

      new file:    hello.txt

This is telling us that Git is now tracking one new file, called hello.txt. Sounds about right to me!

You'll notice that Git mentioned a few new concepts, namely commit and staged (or, as you can see in the output above, unstaged.

In Git, a staged file is one that has changes that you're going to be adding to your next commit (more on that in one second). An unstaged file is one that Git has noticed a change in, but that it is currently ignoring.

A commit is the basic building block of all of Git. By creating a new commit, you're bundling together a set of changes to your project: new files, additions, deletions, everything. By keep track of every change to every file in your project, Git can rewind your project to any point that you made a commit, almost like save points in a video game.

Now, we'll create the first commit for our project. Recall that our project has hello.txt staged, so that's what will be including within our first commit. Creating a commit can be done a few ways, but the quickest way is like this:

git commit -m "My first commit message"

Where My first commit message is a brief description of the changes you made within this commit. This message should be short and to the point -- there are ways to add more details about your changes, but we'll look at that at another time.

3. Branching and Merging

One of the really neat things about Git is that it allows us to have multiple versions of our project on our computer at the same time. This allows Git to associate certain changes with a particular "branch" of your project.

A good way to think about it is with a real-world use case: say you're working on a new feature for a project that is in production (people are using your project in the real world). You need to makes sure you have a version on your computer that matches the one that everyone is using, but you also need to be able to work on new features. By creating a new branch and adding the new feature there, you allow yourself to jump back and forth between your project as everyone else has it, and your project with the new feature that's being worked on. Once you're done with your new feature, you can merge the new branch back into the main branch (called the master branch) and then send that our to your users, creating a new starting point for future branches. This is how Git becomes really powerful -- by allowing you to have many branches for one project, you can neatly organize different changes to your code, but then easily combine these different versions as you finish what we're working on.

So to demonstrate this, we'll go ahead and make a new branch and then merge it into the master. Start out by creating a new branch like this:

git branch my-new-branch

This will create a new branch called, you guessed it, my-new-branch. Now, this does not automatically cause your project to start adding changes to this branch, all it does it create it. You can get a list of all of your branches using the command git branch. Doing so will result in something like this:

$ git branch
* master
  my-new-branch

As you can see, master still has the * next to it, meaning that that is the current active branch.

To switch to the branch that we just made, we'll need to use the checkout command like so:

git checkout my-new-branch

This will cause Git to start tracking changes relative to this branch, as we'll see in the moment. If you check git branch again now, you'll see that the * is now next to my-new-branch instead.

Now we'll go ahead and make a new file, stage, and commit it.

touch new-branch-file.txt
git add new-branch-file.txt
git commit -m "This commit is on the new branch"

Now is a good time to note that it's pretty easy to see a list of your commits with the git log command. You can get all sorts of different views of your project by adding different flags to the command, but we'll just use one that will make the list nice and clean. So, run the command git log --oneline and you'll see something like this:

$ git log --oneline
61919ad This commit is on the new branch
c9a3daa Added commit to revert
2d7390b My first commit message

As you can see, we have 3 commits currently: the two that were originally from the master branch, and then the one that we just created here. To demonstrate how Git tracks the branches separately, switch back to the master branch and then run the log command again and notice how the input only shows the two commits from before.

Now that we've created our new branch and added a file, we want to get our changes back into master. This is done by merging the two branches. So, makes sure you're on the master branch and run the following command:

git merge my-new-branch

That's it! If you check the commit log, you'll see that there are now three commits in the master branch -- Git took the changes that we made to my-new-branch and applied them to master, and we didn't hit any snags. On more complicated projects, this will not always be the case, but that's a more advanced topic that we'll cover elsewhere.

Now that we have all of our changes from my-new-branch in master, we don't need my-new-branch anymore. All merging does is apply the changes that Git tracked one branch to another -- it doesn't remove the branch that was merged. To do this, we can run the following command:

git branch -d my-new-branch

Now, if you list the branches, you'll see that only master is available. If you don't need a branch anymore, it's good practice to remove it to keep things nice and clean.

4. Revert Your Commits

Say that you made a commit or two but you're not happy with the results, and you want to revert back to a previous point in your project. This is actually really easy to do with Git! Since Git understands everything to do with files in terms of additions and deletions, it can easily look at a commit and do the opposite of it. So for example, using the below command...

git revert HEAD

Git will look at the most recent commit to HEAD (the current branch) and create a new commit that does the opposite of whatever was changed. Now, we'll have three commits in our history -- the new one will take the project back to where it was before we branched off and added that new file. By creating a new commit to revert changes, Git makes sure that you can always revert your revert if you change your mind.

It's also possible to revert multiple commits at once. For example, git revert HEAD~1 will roll back the last two commits, HEAD~2 will do the last three, etc.

It's also possible to revert a project to a specific point based on the commit hash. Each and every commit generates its own unique identification number called a hash. If you know the hash for a commit, you can revert the project to that state by doing:

git revert {hash}

---

There is a lot more to know about Git, but this will give you the basics to get you started.