Git is one of the most poorly understood developer tools. There are a couple of reasons for this:

• Git is complex. It has a lot of features and a lot of moving parts.
• Git is poorly taught in bootcamps, schools, and online courses.
• Most people learn git "on the job". This means they miss out on the fundamentals, and lots of powerful features.

This makes me sad, since Git is one of the most powerful tools at every developer's disposal. It is a tool that can help you organize your work, collaborate with others, and document the history of a software project.

I wrote this guide to help show that Git is not as complicated as it seems. This tutorial will show you how to be productive in as few commands as possible.

My favorite aspect of the course is that this is a hands-on tutorial. We are going to build a simple project using Git to track and apply changes. You will not need to run anything on your computer - all of the code will run right in the browser.

What you will learn

We will learn Git by adopting a simple git workflow consisting of 6 commands. This is the same workflow I've used daily for the last 8 years of my career. These 6 commands will set you up for working with Git by yourself (If you don't know why, this reddit post captures why using Git by yourself is a life saver).

I'd like to share one final comment about the nature of this guide: My aim is not to exhaust you with information. My goal is to expose you to the parts of Git that I find most useful. Please feel free to ignore some of these commands. The last thing I want is for you to try and memorize all of them.

In other words, adopt what makes sense and ignore the rest. At the end of the day, Git should serve your needs. Once you know enough to be productive, you have succeeded.

See what commands stick in your mind, and then go out and use them to build stuff. You can always come back to this guide later if you want to learn more.

Ready? Let's get started.

Getting Started

Git is a distributed version control system. It lets developers make changes to files in a reversible, documented, and conflict-resistant manner.

What this means is that Git makes it easy to build, change, and maintain software. To show how Git does this, we will use it to help us build a website for a local coffee shop.

[ Don't worry, we wont write any code. All we will do is focus on learning git. ]

git init

Our project is very simple; It is a single file named index.html. In order to use git in our project, we first need to run one command.

git init sets up git within your project.

If you run ls -al, notice there is a .git directory in the current project.

This hidden directory holds all the information git tracks about our project.

If you ever want to remove Git from a project, simply delete this folder.

git status

Now that we have set up git, lets see the status of our project, through git's eyes.

git status gives us an overview of how git perceives the current state of your project.

We can see that we are on a branch called "main", and that we have not made any "commits" yet. (We will get to commits in a bit, and branches in a later section.)

You can also see that we have an "Untracked file": index.html.

This means that index.html is not being version controlled by git yet.

git add

Let's make sure Git "tracks" index.html.

To tell git which changes you want to version control, you need to git add them.

Lets run git status again and see what changed.

You can see that we no longer see "Untracked files'. This is because all the changes in our directory have been added to git.

In its place, we see another message: "Changes to be committed". It mentions that index.html is a new file that has been added.

git commit

Running git add is only half of the process. To help explain, lets use an analogy of shipping a package.

When you run git add <file>, you are performing the first step when preparing a package for shipment: placing goods in your shipping box.

This first step is flexible. Since we haven't taped the box up and shipped it, we can add or remove things from our package with ease. This is analogous to running git add <file> (adding stuff to the package) and git rm <file> (removing stuff from the package).

Once we are satisfied with the contents of the package, we can move to the next step and commit to send it to its destination. We fulfill this commitment by sealing the package and dropping it off at the post office.

Lets go ahead and complete the work started by git adding index.html

Committing is how you tell git that we are satisfied with our changes, and are ready to capture a record of the changes into the project's history.

When you run git commit, git will open up your default text editor and ask you to write a commit message.

A commit message is a short description of the changes you made. It is a way to tell your team mates what you did.

Lets write a commit message for our changes.

Once you are done writing your commit message, save and close the file.

You can see that git has created a commit with the message we wrote, and that we have changed 1 file.

git diff

We just got pinged by the design team. They want us to add a new paragraph to the body of our index.html. Lets make the change to our index.html file, and see what happens.

now lets run git status to see what's changed.

Git has noticed that we have made a change to index.html, but we can't see the specific modifications done to the file.

Lets run a new command that will show us what exactly changed within index.html.

git diff lets you see the active changes made to the files git is monitoring.

You can see that the changes made were to add a new paragraph to the body of our index.html file. git diff shows us the lines that were added, prefixed with a +. If we had deleted a line, it would be prefixed with a -.

The changes look good. Let's add and commit them.

Notice that we used the -m flag when committing. This lets us add our commit message without opening the default text editor. It's a very convenient way to commit tiny changes that can be described in one sentence.

git stash

Design now wants us to add a footer to the site. Let's go ahead and do that.

We've made the change. Let's go ahead and add it, and commit it to git...

Wait! Our designer came rushing back, and said we need to put the footer on hold. The design manager wants to review the footer, but won't be able to give feedback until tomorrow.

We need to put the footer on hold. We don't want to commit it yet, but we also don't want to discard it, because we want to keep it around for later.

luckily, there is a git command for stashing away changes that you don't want to commit yet.

git stash lets you move any changes from your working directory into a special place called a "stash". This is useful when you want to save your work, but don't want to commit your changes yet.

We can see that our changes have been stashed away. If we run git status, we can see that our working directory is clean.

You can keep stashing changes as needed. The stash mechanism works like a stack; each new stash will sit on top of the previous one.

To view all of your stashed changes, run git stash list.

To preview the contents of a stash, run git stash show -p <stash name>. The -p flag tells git to show the diff of the stash.

once we are ready to bring our changes back, we can run git stash pop to bring the changes back into our project. Here is what that would look like.

we can see that our changes have been brought back into our project. When we ran git status, we saw that our working directory is dirty again.

Let's keep these changes stashed, and take a break for now.

Summary

To recap, here are the commands used in a simple git workflow:

• git init: set up git within a project's root directory
• git status: view the changes to your project
• git add: mark a change as ready to be committed
• git commit: store a record of the git added changes to our project's git history
• git diff: view the line-by-line changes of all files tracked by git
• git stash: save your changes without commiting them

We've covered a lot of ground already. If you're a solo or hobbyist developer, you have already learned enough to be dangerous. With these commands you can build a rich history of your projects.