There is nothing worse than getting a ton of work done only to realize later that there are major mistakes. Git is a powerful version control tool used to save backups of code so we can avoid this problem.
cd [nameOfDirectory]: a command to change directories.
ls: a command to list all files within a certain directory.
git init: a command to initialize a new Git repository
git add [fileName]: a command to add a specific file to be tracked.
git add -A: a command to track all changed/new files to be tracked.
git commit -m "message": a command to commit changes to our Git repository.
git log: a command to view a list of all commits made.
git checkout [branchName]: a command to switch branches.
git checkout -b [branchName]: a command to create a new branch.
In this chapter, we will cover the basics of using Git for version control. While Git has lots of facets we could explore, we will be focusing on the basics in this chapter so that you can get up and running with it as soon as possible.
To begin, press
Space to open Spotlight. Search for Terminal and press
Enter to open the Terminal app (Figure 1.14.1).
Inside the Terminal window, we can write commands. If you've never written commands in Terminal before, this can seem scary or intimidating at first, but don't worry – we only have a few commands to learn.
Note: After typing a command in Terminal, you must press
Enter to execute that command.
In Terminal type the following to change directories (cd) then press
$ cd Desktop/
The active directory in Terminal is now our Desktop. Next, type the following to create a folder on our Desktop named git-fun:
$ mkdir git-fun
On the Desktop, there should now be a folder called git-fun. If there isn't, ensure that the active directory is actually set to the Desktop (Figure 1.14.2).
In Terminal, type the following to change directories to
$ cd git-fun/
Git is already installed on your Mac (thanks, Apple! 🙌) so we can use it right out of the box. But first, we need to create a file for Git to manage. Type the following to create a README.md file:
$ touch README.md
To verify that our file was created, we can use the command
ls to list all files within our active directory, which happens to be
$ ls README.md
You should see that README.md appears beneath where we typed the
Now we have a file Git can manage and back up.
We want to open our file to add something to it's contents so that we have something to revert back to later.
Vim is a terminal-based text editor which can edit documents directly within Terminal – no need for an external editor. Like Git, it is also installed on your Mac by default.
To edit README.md with Vim, type:
$ vim README.md
You should see a screen like the following (Figure 1.14.3):
Now, to insert data into README.md, we need to press
i to begin 'Insert Mode'. You should see "-- INSERT --" at the bottom.
Type in a title like in Figure 1.14.4:
To close and save our file in Vim:
Enterto save README.md.
To begin using Git, we need to initialize a repository which will manage and store all of the files we tell it to. To see if we already have one (hint: we don't.), type the following:
$ git status
You should see an error message similar to the following:
fatal: Not a git repository (or any of the parent directories): .git
Ensure that your active directory is still
git-fun and initialize a new Git repository (repo for short):
$ git init
Terminal should return with:
Initialized empty Git repository in /Users/your-name/Desktop/git-fun/.git/
Check the status of Git once more by typing:
$ git status
Now, we see a different message than we did before. When we run
git status now, we see that we are
On branch master, a list of untracked files that Git isn't sure what to do with, and that we have not yet added any files to a commit (Figure 1.14.5).
Great! This means that we are ready to start tracking and committing files!
Git just told us that we aren't tracking README.md yet, so if we want to back it up we need to add it. In Terminal, type the following then press
$ git add README.md
Now if we type
git status we see that our files which were once red show up in green now and that our changes are ready to be committed (Figure 1.14.6).
We are now ready to make our first commit. That simply means whatever files we have added to our Git repository will be timestamped and backed up as they currently are. After committing our changes, we can revert back to this exact point later on if we want.
Let's take a leap of faith and make our first commit to back up our README.md file.
Type the following then press
$ git commit -m "First commit ever."
To commit files it is required that you write a message in regards to the changes or additions you've made.
git commit, we used the command
-m indicating that we want to write a message and then ended with a message in quotations.
Note: It is good to be specific about what changes have occurred.
Enter you should see the following message print out below (Figure 1.14.7):
git status to ensure that our commit was performed properly (Figure 1.14.8):
This means that we have successfully committed our changes and backed up our code! Pat yourself on the back. Nicely done. 👌
We are now going to make changes to README.md so we can practice this process one more time.
K to clear the Terminal window. Ensuring that you are still in the active directory
$ vim README.md
Now our file is open in Vim and we can modify it after pressing
i to activate Insert Mode.
Add a couple lines of writing so that we can make a change for Git to track (Figure 1.14.9).
To save and exit Vim:
Enterto save README.md.
git status into Terminal and press
You should see the following message printed in the Terminal:
Now we are told that we have a file being tracked and a file that was modified and has changes in need of being committed.
We will commit those in a moment, but for now let's create a new file. This will show how to manage the scenario when you've created, tracked, and committed a file but add or modify a different or new file.
$ touch code.js
git status to see what happened (Figure 1.14.11):
As you can see above, we have both files with changes and new files that have not yet been added.
While we can add and commit each file individually, it is much more efficient to perform two actions in one.
add command in Git works on changed files and brand new files, too.
In Terminal run the following command then press
$ git add -A
git status to check what happened (Figure 1.14.12):
The next step is to commit our changes. This will make a new backup including our changes to READMD.md and the new file code.js too. Type the following, just as before:
$ git commit -m "Modified README.md and added code file"
Enter and Terminal will tell you that you have modified and added a file similarly to before.
git status and press
Enter. You should see the same message from when we committed changes earlier on (Figure 1.14.13).
What if we committed those changes, but then realized that we had introduced a massive bug into our code base? How would we fix this problem?
Reflecting on this chapter's example you may be thinking, "No big deal! We only have two files that we changed." That's true, but when working on an app, especially with a team, there can be hundreds – even thousands – of lines of code that you're committing at a time.
If we want to revert back to a previous commit when things were happy and sunny and made sense, all we need to type into Terminal is:
$ git log
Enter and look at the message that get's printed out (Figure 1.14.14):
We can see a list of all the commits we've made so far. Each commit has a unique ID, author, date, and message.
I hope you can see how important writing a descriptive message is. It is really helpful in thinking back to what you were doing at the time of that commit so that you can pinpoint what may have gone wrong.
To go back in time (a la Huey Lewis and the News), you need to type
git checkout followed by the first 7 digits of the unique ID for the commit you want to revert back to. For instance:
$ git checkout 69f0082
Terminal will return this message to us (Figure 1.14.15):
To check to see the state of our
git-fun folder, type
ls into Terminal and press
You should only see README.md now. But where is code.js?
Since we reverted back to our first commit, code.js no longer exists because we created it after the fact. Amazing work, Git! 🤘
Let's check to see if the contents of README.md have changed back also. Type
vim README.md and press
Enter to open it in Vim. You should see the following (Figure 1.14.16):
Voilà! README.md has been sent back to the state of it's first commit.
To exit Vim:
Enterto save README.md.
A branch in Git is a grouping of code. Usually, when working on a project you will be implementing one new feature at a time.
Developers usually make one branch per feature. But before I explain more what branches are in Git, first type
git branch into Terminal** and press
You should see something similar to the following (Figure 1.14.17):
As you can see, there are two branches:
master and another that says
(HEAD detached at 345c39f).
The asterisk (*) indicates what branch we are currently on.
The problem with the branch we are currently on is that it doesn't have a descriptive name... Let's give it one!
In Terminal type the following, then press
$ git checkout -b readme-one-line
Terminal will respond with something like:
Switched to a new branch 'readme-one-line'
The command we typed above, "checked out" a new branch, as indicated by
-b and then at the end we gave our branch the name
git branch to see what branches are available to us (Figure 1.14.17):
As you can see,
readme-one-line is now an official branch.
If we wanted to switch branches, we use the keywords
git checkout followed by the name of the branch we want to switch to. For example:
git checkout master
Enter, Terminal should print:
Switched to branch 'master'
If you type
ls and press
Enter in Terminal, you will see both README.md and code.js now because master has always contained our most up-to-date code.
If you open README.md in Vim, you will see that both lines wrote are there.
When we went back in time earlier, Git actually created a temporary branch with our old files leaving our newest ones untouched on the branch
master. When we created the branch
readme-one-line we saved those old files to
After going through this chapter, you are now ready to start using Git right away. You should be using Git with EVERY project.
If you want to be a professional developer, you will definitely be using version control (likely using Git), and even as an independent developer, it's a very efficient way to manage and safe-proof your code.