If you have to learn how to use git from the command line, I wrote this tutorial to help you.
It lays out all the basic / fundamental commands, with both a written description and a visual through tiny, soundless videos (technically not gifs, mpegs just compress way better.)
Git is a complex tool. Programmers use it in their workflows so they have an easier time working with others on the same code base.
If you’re new to git, you only need to drill down a handful of commands into your memory. Once you memorize these commands and understand how they work, you’ll be ready for the races.
Here’s our list of the top git commands. We created videos of all the commands, and they go in order showing you the creation of a git repository, adding and changing some files, and pushing it to a remote repository (github in this case since that’s what you’ll most likely be familiar with, but I also recommend taking a look at gitlab, or bitbucket for some more private alternatives.) So without further ado, let’s look at the commands:
Note, you may have to click play before the videos will start.
There are basically two ways to start using git. It depends if the project is already on git or not. In practice, you actually start most git projects by cloning an existing project because you’re joining projects at work or in open source more often than you are starting new projects. Even so, we’ll start this tutorial with initializing git in a new empty folder and get to cloning towards the end of the tutorial. Regardless of how you start a git project, the end result is that you have a folder you can run git commands in.
You can’t run git commands in a project folder unless there’s a git folder in it. Every git project has a .git folder (that’s “hidden” unless you turn on OS settings), because that is where the git program keeps its data about your project. As you can see, we create a .git folder by running the git init command. The directory you do this in doesn’t have to be empty like in our example — you can easily bring an existing project onto git by running git init in the directory.
While git status doesn’t make any changes (it simply gives you back information), we’re showing this command second-up because of how useful that information is. Whenever you’re unsure about about what git has on your project, just run git status.
You can see in the gif, after we created a file and ran a git status, it told us useful stuff like:
- Git sees the new file, but it is not being tracked
- It’s not being tracked because we haven’t added it to git
- To add it to git, run the git add command
Git’s job is to track the changes you (and others) make to files over time. Being a tracked file is kind of a big deal. Git isn’t just going to start tracking everything automatically, because you might have sensitive files (such as those containing application keys) or files that don’t need to be tracked (maybe cache files.) So to get files inducted into git, you have to manually add them.
You can add files individually by writing out their path,
git add /path/to/file.txt
But usually what people do is add all using a dot (known as a wildcard)
git add .
This is done after running a git status just to confirm what files are going to be added, and using a .gitignore file to black out files and directories that don’t need to be tracked.
If you’ve heard of git, you’ve probably heard of “commiting.” This is one of the core actions to using git. What you’re doing in essence is creating a “snapshot” of all the files you have git tracking.
Watching the gif above, you will see the basic lifecycle of working with git. You commit, you make changes, you commit, etc. Of course, you don’t have to commit for every file save — just when there’s a coherent place to take a snapshot of your work. Git stores all the changes you make in “deltas”. Basically, instead of making a copy of all your files every time you commit, git is smart enough to just save the changes from one version to the next. These are stored in the .git folder from the first step.
This is another command for getting info from git. Using git log, you can see the commits that have been made along with their hash id. Git uses hashes to refer to all the commits it has in its database.
We included this command to introduce the concept of looking at past commits — you don’t have to use the actual git log command. All git repositories (e.g. github) have intuitive user interfaces that are simply put, a lot better for looking at commit history than using the command line.
Branching in git is a little bit less intuitive for newbies. The easiest way to think about it is having different versions of your code that you can switch between with a quick command.
As you see in the gif, I create and change to a branch for restructuring my directory. I make some pretty major changes — creating a folder, deleting a file, renaming a file and editing the contents. I then commit these changes.
But I can also go back to how things were before! Since I had made my changes in an alternative branch called restructure_directory, I can always go back to how things were before by going back to the main branch called master in git-speak. This shows the power of git because now my directory will be exactly as it had been before. And of course, I can go back to my changes just by checking out restructure_directory again.
Yet another “informational” git command, if you ever want to know what branches exist, just type git branch. It will also tell you which branch you are currently on (though git status also gives you that information!)
So let’s start doing what makes git interesting and start saving our code to repositories. We’ll start off by creating a repository on Github. Sidenote: If you don’t have a paid account on Github, they force your code to be public which isn’t a problem in this case. But if for future reference, bitbucket has free private repositories.
Once we make the repo, we run (replace the URL with your own)
git remote add origin http://github.com/username/reponame.git
Origin in this command is another git-speak term. We use that as the name of the “official” repository of a project. So we’re telling git, add a remote repository called origin and it’s URL is this.
Once we added a remote repository called origin to git, we can now “push” or upload our code to it. The gif below has some hiccups I intentionally left in because that’s what you’re going to see unless you take the time to setup git and github.
When I try to just do a git push, the first error I get back says “the current branch master has no upstream branch”. To translate that from git-speak, it means that git didn’t find a branch called master on the repository (because it’s brand spankin’ new), and it doesn’t want to be so bold as to create one automatically unless we specifically request it with the
--set-upstream origin master
option. Including that option, we tell git to “link” our local branch that we’re on with a branch on origin (remember, our name for the repository) called master. Since we were locally on the branch master, we are telling git to link local master to a remote branch called master.
We then get back another error, this time with authentication. Now what most people do to setup git and github, is they upload their public key to github (or their repository of choice), and then locally they tell git what their private key is. Doing it this way, the repository can authenticate you without any usernames or passwords. But in this gif, I have it just ask me for my username and password. Once I put those in, the push works and we can see that the code has been uploaded to github!
Let’s try another experiment now. Let’s say we like the changes we have in our other branch, restructure_directory, and we want it to be the main version. To do that, we have to merge the two branches.
Just switch to master, and run
git merge restructure_directory
and it will change master to match! Some things to note. After we merge and ask git to tell us what branches exist, you will see that restructure_directory is still there! When git merges a branch, it doesn’t delete the source branch. Though often, that’s a good idea and people run the appropriate command to delete the unnecessary branch after for housekeeping purposes.
git branch -d restructure_directory
If you caught the git status in the last gif, you’d notice it said something about us “being ahead of the remote repository by 1 commit”. Whenever we make changes and commits, git compares it to the version it thinks is in remote and tells you how different you compare. Cool right? Git will get it right if you’re the only person working on the project. But the remote repository can change if other people are working on it. So, whenever you start a new coding session, run
Before hand so that git syncs up and knows what the remote repository really looks like. Git fetch doesn’t make any changes, it’s just how you nudge git to look at what’s out there, what other people have done lately so that it can give you the correct information.
Now, let’s do the last step of what makes git really cool!
In this gif, we start off with pushing our changes after we merged the other branch into master. Then, we delete everything. But using git clone, we are able to recreate exactly what we had from github! As mentioned at the start, cloning is the way people join projects. You git clone an existing repository, and your folder is up to date with all the code, all the branches, all the history, everything!
Thanks for making it to the end! If you were new to git, I hope this gave you some lay of the land. If you can think of a place to share this tutorial, I’d appreciate it.