I love git
Git is absolutely great. Once I learned how to effectively utilize the tools that git offers, I discovered a large part of me (the same part that loves tidying, organization, and keeping regular backups) received immense satisfaction from using it everywhere that I could. If used correctly, git helps keep projects of all sizes versioned, neat, and up-to-date. You can even use git for some advanced deployment techniques to remote servers, but that is outside of the scope of this article…
All of that being said, git can be a little daunting (and terrifying) for new users. Especially for those that aren’t as familiar with the command line. There are a plethora of sites out there that are available for helping one learn git, but I found the majority them a bit hard to understand. This very well could be because I’m an idiot, and sometimes I need someone to hold my hand and tell me that it will all be ok. But, for all those out there that might be the same way, here’s a simplified intro to the power and majesty of git.
What is git?
Git is a versioning tool. In its simplest form, git is used for two main reasons:
- To keep lightweight “backups” available, just in case you need to roll a project back to a previous version
- To help teams create and merge different versions of a project easily and without taking up a bunch of space (again, in a lightweight fashion)
You’ll notice my use of lightweight in both of those bullet points. In my heart of hearts, this is one of the key features of git that I appreciate the most. You get all of the great advantages of keeping different versions of whatever you’re working on, without having to make physical (Ok, digital) copies over and over. It’s just fantastic.
Since this article is called “Git Simplified”, that’s the farthest that I’ll dive into the definition of git. For a more in-depth look into what git is, feel free to look at the official git docs.
Ultimately, no matter how much you read about git, it won’t make a whole lot of sense until you start using it. So, here is a small tutorial on using some of git’s most popular and common features.
Note: The following tutorial will cover basic local usage of git, including staging, committing, and reverting. Another post on git branching (core feature #2 of git) is forthcoming. So git branching, both local and remote, will be covered there, not here.
Before starting the tutorial, you’ll need a directory to work in and something to edit. The beauty of git is that you can use it for keeping track of anything (at the time I wrote this, I’ve used git on small-large coding projects, Word Documents, MS Project files, and much more).
So, to keep this tutorial as general as possible and to account for many different skill sets, I’m not going to dictate what type of file(s) you will need. At a high level, you’ll need the following before continuing:
- A directory (folder) on your computer
- A file or multiple files in that directory to edit
- Access to the command prompt/terminal
- Git installed on your machine (see this article on installing it for your respective OS)
Once you’ve got all of the following items in order, you’re ready to start using git.
Note: You’ll see in some of my code snippets below that I refer to certain directories and files by name, like DevProjects, or GitTut. You’ll want to replace those names with the names of the directories and files in your personal file structure.
Initialize a Repo
Repo – meaning, a git repository. This is where git does all its magic.
To begin, open up your terminal and cd into your directory.
You’ll then initialize a git repo in this directory. Doing this will create a hidden folder inside of the project directory called .git which allows git to do work inside the project directory.
If successful, you should see something like this:
Now that there’s a repo inside of your project, you can start versioning.
Making Your First Commit
Commit – the “snapshot” of your project
With a git repo in your project, you’re ready to start off your magical, versioning-journey with your very first commit. But, before you’re able to make any commit, you need to stage your files first.
Staging – “taking note” of any modified files since the last commit
The fact that you need to stage your files first before committing them may seem a bit odd, but think of it like this: Before taking a picture of anything, you usually take time to look through your lens (or smartphone screen) to frame your picture. Staging is the framing process before taking your git snapshot. So, run the following commands in your terminal.
git add --all
git commit -m "My first commit"
Let’s break these commands down. First of all, the git add command frames your project in preparation for your snapshot. The –all flag means “get ready to take a snapshot of ALL modified files in the project since the last commit, including taking note of any files added OR deleted.” This is something that you’ll want to use when you’ve deleted files from your project and you want git to take note that the file no longer exists in the project. Personally, I use the –all flag for the majority of my stages, but if you haven’t deleted any files from your project, a common staging shorthand is the following:
git add .
Note the period at the end of that command!
The second command is the actual committing process, or the act of taking the snapshot. The -m decorator means that you’ll add in a message to your commit to describe what changes you’ve made since the previous commit.
Congratulations! You’ve just created your first commit! To see your commit, go ahead and type the following command:
You should see something similar to this:
Editing Your File
So, you’ve made your first snapshot of your project. Now you can see the real power behind git. Go in and edit whatever file you’ve placed in your project directory. If you have multiple files in your directory, then feel free to edit one or many (or all) of the files. Maybe add a new file, or delete a file from the directory. Basically, make whatever change you want to the directory in preparation for taking a new snapshot.
Once the changes are made, check the status of the directory using the following command (note, this step is optional, but it’s nice to see if you’ve made any changes to your directory since the previous commit).
Your terminal output should look something like this:
Note that the output says “changes NOT staged for commit”, meaning that git has detected changes, but they’re not staged, or framed, for your snapshot.
So, repeat the process above for staging and committing your files, only this time, replace the message “My first commit” with a description of whatever change you made.
git add --all
git commit -m "Added in new feature to test.txt"
Now run git log again to see your commits. Your output should look something like this:
Notice that your commits are now listed in chronological, descending order.
Reverting to a Previous Commit
Reverting / Rolling Back – Returning your code to a previous git snapshot
Now that you have 2 commits in your logs, you can really experience some git goodness, by rolling back to a previous version. Imagine the following:
You’re working on a project for your personal website. You’ve got a great site running, but want to add a cool new feature. So, you edit the code and add the feature. You run some quick tests locally and think it’s working just fine. So, you push that code live and immediately your sever blows up with errors. You missed a critical bug. Good thing you’ve got a git repo!
It’s easy to roll back to previous git commit. You won’t even need the commit ID for it. Let’s roll back to the previous commit we made using the following command:
git revert HEAD
Reverting back to the previous commit actually does something a little counter-intuitive: it creates a new commit with the files in the same state as they were in the targeted snapshot. I won’t get into the details of this, but I highly recommend reading this article from Atlassian. It explains the difference between git revert and git reset, which performs a VERY different function.
There are also other ways to revert commits, for various other use cases, including reverting back to a specific commit, reverting back a range of commits, cherry-picking different changes made by a certain commit, etc… As you become more and more familiar with git, you can start to do some really great things with your project. If you’re interested in learning more about rolling commits back, check out git’s docs.
Wrapping Up and Moving On
Alright! You’ve started on your way to a great world of lightweight version control using git. There’s still a lot to learn, especially the great ability that git has for branching. There are also some more advanced features that we didn’t discuss here, such as the
rebase command, which is one of my favorite ways to keep your commit history nice and clean. Check out my other post on rebasing in git.