Here you will find a quick, high-level overview of some of the major Git commands along with short descriptions and examples. For simplicity, the commands are divided into four sections: initializing, staging, committing, and maintaining. Specifically, we will be covering these commands:
Before you read on, I assume you have Git installed. You also want to associate your email address with your account.
Check to see which email address is associated to Git:
You can update the email if necessary:
As you probably know, Git is a version control system, which allows you to save snapshots of your projects into repositories. Before you can start taking snapshots though, you have to establish a repository by either creating one from scratch or by copying an already established repository.
git initinitializes a new empty repository on your local machine:
git clone <url>clones (or copies) a git repository to your local machine. When you clone, you do not need to initialize a new repository because cloning copies all files, including the actual repository.
1 2 3 4 5 6 7
To see the repo, navigate into the directory and then view all files. You’ll see a hidden directory called “.git”, which is the actual repository:
The goal of really any version control system is to save periodic snapshots of your projects. Once you have a snapshot saved, you can feel safe working on your project as you can always revert back to an earlier snapshot if you make a huge error.
If saving the snapshot is the goal, then staging is the actual act of taking the snapshot before you add it to the photo album (repository) for safe keeping.
git add <filename>adds a new file to staging. This file is now ready to be committed. Remember, you have taken the snapshot but not saved it yet. It’s in the queue waiting to be added (or committed) to your local repository.
git add .adds all files in the current directory and all sub directories to your local working directory.
git statuslists all files ready to be committed, which have been added to staging, and files not currently being tracked by Git. Use this command to view the state of your working directory and staging area.
I added “readme.md” to staging. However, there’s another file in the directory, “test.md”, which has not been added. Let’s see what
git status has to say:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
So, while “readme.md” is in staging, ready to be committed, “test.md”, is not being tracked.
1 2 3 4 5 6 7 8 9 10 11 12
After taking a snapshot, you want to move the snapshot from staging to your actual repository. Committing achieves this. From there you have the option of continuing to work locally or sharing those commits to a remote repository, perhaps on your web hosting platform or on Github.
git commit -am ‘<add note>’commits new and updated files - moving them from the staging queue to your local repository. Make sure the note you add is relevant - that is, it summarizes the changes or updates you’ve made.
1 2 3
git status say now?
1 2 3
git push origin mastergathers all the committed files from your local repository and uploads them to a remote repository. Keep in mind that not all files are included in the upload; only new files and files that contain changes. Put another way, this command syncs your local repository and external repository so they are exactly the same.
Before you can push, you must add a remote repository to share your local repository with, which you’ll see in the example.
1 2 3 4 5 6 7 8 9
Success! Take a look at my remote repo on Github, which has identical copies of my files from my local working directory and repository.
The more you work with Git - or any version control system, for that matter - the less you’ll spend simply taking (
git add .) and saving (
git commit) snapshots. Maintaining (both local and remote) and ensuring your local and remote repositories stay in sync can be incredibly time consuming.
This section could easily be split into multiple sections, with five ot ten commands each. However, most readers will follow a pretty straight forward workflow of initializing, staging, and then committing, without having to stray too far into maintenance.
git pull origin masterliterally pulls the changes made from a remote repository to your local repository. Perhaps you are collaborating on a project and need to pull changes down made by your collaborators or maybe you’re just working solo and updating a local repository on different computer.
To demonstrate a basic pull, I made changes to the “readme.md” files on the remote repository. I want those changes to reflect locally, so I can simply pull them down.
1 2 3 4 5 6 7 8 9 10 11
You may have heard of the
mergecommands. Well, the
pullcommand literally is a combination of both those commands. In essence, you are first “fetching” all the changes, then “merging” those changes. In the example above, I fetched the changes made to “readme.md”, then merged the two files. Keep in mind that most merge situations are never this simple, and problems can arise in the merge process, which can be difficult to solve.
In the example, I changed the text within “test.md” both locally and remotely: - Local: “testing merge” - Remote: “merging test”
If I just try to
pull like normal, I will run into errors:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
So neither command worked. You can see in the stack trace some helpful hints. Basically, I can do a fast forward in either direction (PUSH or PULL), which forces the changes by adding an
-f to the end of either command:
1 2 3 4
In small, trivial situations, it’s perfectly fine to use this method of merging. However, when you are dealing with complex code, you will definitely want to take a different approach - which will be covered next time.
git logis used to view the history of your repository.
1 2 3 4 5 6 7 8 9 10 11 12
Here we can see the local commits, along with the commit number, author info, date, and the note from the commit - which is exactly why it’s good to use detailed messages with your commits.
git reset --hard <commit number>is used for reverting back to a particular commit. Check the logs to find the commit number you want to revert back to. If you ever submit code that breaks other code (which will happen), use this command to discard that commit and roll back the entire repository to the commit you specify. Continuing with the snapshot analogy, perhaps you took and then saved three bad pictures of yourself. Well, you can use this command to discard those pictures.
So I went ahead and made another change to “readme.md” and committed the files locally. I now have three commits according to the log:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Let’s say I made that last commit on accident. How do I correct?
By using the ‘reset’ command I completely discarded the changes from the last commit. The file even reverted back. It’s like the changes never happened:
1 2 3 4 5 6 7 8 9 10 11 12
Back to the previous state. Yay!
Again, these are the basic commands - and the commands that I use the most. Next time we’ll go over some of the more advanced commands and I’ll detail a workflow you can follow for when you work with more than one person on a single project. Cheers!