Chances are you’ve been frustrated by Git at some point in your programming career. If that point is right this second, don't worry. While Git is a complex system, getting a handle on a few common Git commands and the general idea of how repos work will dramatically flatten the learning curve for future work and let you easily submit and track changes to your code.
First off, if you’re completely new to Git, here’s a quick definition: Git is a distributed version control system (DVCS) that allows developers to track changes in source code for documents, websites, programs, and other collaborative projects. Unlike outdated centralized version control systems (CVCS), Git utilizes a remote server that allows developers to clone data to work on a project in parallel.
There are hundreds of Git commands programmers and data scientists can use to change and keep track of projects. Don’t worry, we’re not going to subject you to a novel about them all, instead we're going to list off 13. Anyone can remember 13 Git commands. (Editor's note: even me!)
If you’re starting a project on your own from scratch, one of the first things you need to do is create and initialize your local repo.
You won’t be able to run the other commands until you use git init, so start here. This command creates a .git subdirectory locally, which will have all the necessary metadata for your local repo moving forward.
Or transform a current directory into a Git repo with:
git init <directory>
git config is a convenient way to configure personal info, settings, and preferences globally, locally, and system-wide. The most common use case for git config is to set your contact info and name. This ensures other developers know who submits what code.
git config --global user.email <your-email> or git config --global user.name "your name".
If you’re contributing to an existing project, the clone command creates a copy of your remote rep (generally via GitHub, GitLab, or Bitbucket) that you can make changes to without overwriting the master version.
This command gives you access to a copy of the source code on your local machine that can be changed without compromising the master.
To download your project, use this in your terminal:
git clone <repo URL>
When you’re working with other developers on the same project, branches allow you to both modify and reference copies of the same sections of source code and merge the differences later on.
This avoids the errors and broken code/features that would happen if you were both making changes to the same code at the same time.
Create a new local branch with:
git branch <branch-name>
Push this local branch to the remote repo with:
git push -u <remote> <branch name>
View existing branches on the remote repo with:
git branch or git branch—list
And delete a branch with:
git branch -d <branch-name>
git checkout lets you move between the master branch and your copies locally and can be used to inspect file and commit history.
By default, the local clone of your master branch is the one that you’ll start out in. To make changes to a different local branch, you’ll need to run the command to switch between them. Note: Before you switch, make sure that you commit or stash any in-progress changes; otherwise, you may run into errors when pushing changes to the remote repo.
git checkout <name of your branch>
Or create a use this to create a new branch and switch to it with one command:
git checkout -b <name-of-your-branch>
git add ensures that changes across your branch, or singular files changes, are staged for the next commit. While the verbiage is a little confusing, a commit actually includes two steps: stage and commit.
The git add command essentially queues your changes to be included when you commit at the local level.
For single file changes use:
git add <file>
Or use the below to stage all changes if you’ve made a bunch of them:
git add -A
Has it been a minute since you last made changes to your project? Have you been flying through code and everything is blurring together? You’re in luck: The git diff command lets you quickly compare files that aren’t staged yet and see where the differences lie.
For all local files:
Or, for changes to specific files:
git diff <file>
git status is a quick way to see the status of your local repo and staging area. This command shows a quick picture of any changes that haven’t been staged and any files that are being overlooked by Git.
And if you want to remove a change from your next commit, you can do so with
git reset HEAD <file>....
Commit essentially acts as your local save point for changes made to a local branch or repo.
After you’ve made your changes, staged them for commit using git add, and checked to make sure no changes to the remote repo will conflict with your local changes, use git commit to create a checkpoint you can refer back to.
Additionally, make sure to replace the “commit message” below with a succinct but descriptive summary of the changes you made.
git commit -m “commit message”
And if you want to see the information about a previous commit, use this to display metadata and content changes:
git pull is a combination of the git fetch (which downloads all the changes everyone else has been working on from the remote repo) and the git merge (which integrates those changes into your local code) commands.
Before you push changes to your remote repo, you need to make sure that the updates you’ve made don’t conflict with the code changes that may have been added by other developers since you first ran the clone command.
git pull <remote>
Congratulations! If you’ve made it to this step, it means you’ve completed the development in your branch, and everything is working smoothly. Now, you can use git merge to combine your local branch with your local parent branch (dev or master).
Note: Before you do this step, make sure you’ve compared your local branch with the remote repo with git pull one last time.
You can specify what branch you want to merge to with:
git checkout dev
Update your local dev branch with:
Or merge your feature branch into another specific branch with:
git merge <branch name>
git push delivers your commits to the remote repo, so the rest of your team can review and test them. This command only uploads changes that were staged (via git add) and committed.
Once you’ve committed your source code changes, you can send your updated project to your team’s remote server repo. The point of doing this is to prompt your team to do a QA check on your work and merge it on your behalf.
git push <remote> <branch-name>
Or (for newly created branches):
git push —set-upstream <remote> <name-of-your-branch>
git push -u origin <branch_name>
What happens if you made a mistake in your code, or you need to undo a change that’s causing error or conflict? First, don’t panic. Second, use git revert. This command will undo a previous commit without erasing the commit history, making it easy for you and your team to see the complete code timeline.
git revert makes it easy to undo a change. You can do this in a number of ways in Git, but revert is the safest, especially if you’re modifying your remote repo and want to make sure you’re not deleting code your teammates may need.
First, review the master branch commit history with
Then specify the commit’s hash code with
git revert <hash>
The above 13 common Git commands will get you (get it?) pretty far, but at the end of the day, each project’s use case is unique, and you really shouldn’t stress about learning hundreds—or thousands—of commands. Google is your friend. Your best friend. And it won’t even ramble on for 15 minutes about “how easy Git is" before helping you.
Use this article as a reference for the basics. From there, learn the commands you need as you go with a quick internet search or through cool tools like Git Command Explorer, which will quickly serve up the command you need for whatever you’re trying to get done.
Nothing to see here...