Here Are 7 Git Commands Every Developer Should Know

Git is a one-size-fits-all tool that lets developers share and organize their code

Indrek Lasn
Jan 6 · 5 min read
Photo by Yancy Min on Unsplash

Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning-fast performance.

This article serves as a light introduction and a pointer to what employers expect junior developers to know before they start working in a professional environment.

Without further ado, here are 7 git commands every developer should know.


git add

The git add command lets you commit files to your repository. Quintessiall to everyday development, especially when working in a team. Every employer expects you to know how to add files to a repository.

git add

Hint: The . specifies to add all modified files. Think of it as a shorthand forgit add --all.

The git add command updates the index using the current content found in the working tree, to prepare the content staged for the next commit

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
[--dry-run] [(-c | -C | --fixup | --squash) <commit>]
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
[-i | -o] [-S[<keyid>]] [--] [<file>…​]

Read more about git add here. The official documentation is a great place to learn more about git.


git commit

git commit lets you create a new commit containing the current contents of the index and the given log message describing the changes.

git commit

Whenever you finished working on a feature, the git commit lets you save the progress you made. Think of it as “save changes” with source control. To “push” the changes to the git repository, we’re going to issue the git push command.

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
[--dry-run] [(-c | -C | --fixup | --squash) <commit>]
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
[-i | -o] [-S[<keyid>]] [--] [<file>…​]

Read more about git commit here.


git push

Once you’re convinced you to want to update the repository and made all the appropriate commits — git push lets you push the commits to the repository.

Pushing a commit to the repository
git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
[-u | --set-upstream] [-o <string> | --push-option=<string>]
[--[no-]signed|--signed=(true|false|if-asked)]
[--force-with-lease[=<refname>[:<expect>]]]
[--no-verify] [<repository> [<refspec>…​]]

Read more about git push here.


git status

git status compares the current working head with the latest commit and displays the changed files.

git status

Notice the files in red are the unsaved changes.

git status [<options>…​] [--] [<pathspec>…​]

Read more about git status here.


git diff

Similar to git status — the git diff gives you a clear idea of which files have been changed. It compares active changes with the previous commit.

git diff

Hint: The code highlighted by green are the unsaved changes, while the red is the previous commit.

git diff [<options>] [<commit>] [--] [<path>…​]

Read more about git diff here.


git checkout

Let’s say you’re working on a new feature and suddenly you get an emergency call from your client. The client found a critical bug and wants you to fix it as soon as possible. Is there a way to save your changes without pushing the unfinished code to production? Fortunately yes! It’s called branching in git.

Branching lets you create a separate branch for a feature or a hotfix.

git checkout

Notice my command line displays me which branch I’m currently on. I’m using the “oh my ZSH!” terminal.

git checkout [-q] [-f] [-m] [<branch>]

Read more about git checkout here.


git merge

Now that we fixed the critical bug, the question is how do we get our code on the master branch? We made our critical changes on the my-criticl-bug-fix-branch and now we can use the git merge command to merge the changes into the master branch.

git merge

Voila! Don’t forget to clean up unused branches. We can delete branches with the git branch -d [branch-name-here] command.

git branch -d

syntax

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
[--[no-]allow-unrelated-histories]
[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>…​]

Read more about git merge here.


Conclusion

Thanks for reading, I hope I managed to nudge you in the right direction when it comes to using git. Happy coding!

Indrek Lasn

Written by

JS, Swift, C++ Indie Dev. Oh, and startups. Connect with me on Twitter @ https://twitter.com/lasnindrek

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade