You heard me.
Alright, that was mean lol. Though based on the title, you probably already knew the idea of this article.
Git was something we have all heard. Don't get confused with GitHub though. They are both different.
I have used Git, but not in a way most people have used it, which is via GitHub Desktop. I have used GitHub Desktop since the beginning because of its friendly UI and how it is easy to use.
So what's the issue? The issue is that I am using GitHub Desktop. I have "Git" on my resume and it just feels wrong since I have been using a UI.
I thought it would be a great idea of learning Git via CLI. That way, I can understand from both worlds of UI and in the command line! I know it's difficult sometimes to learn something new, so I thought it would be best to get community feedback on other commands I should learn and in hope this article will help other new and existing developers to fresh up some Git.
With that said, if you are a type of person who relies on UI for Git and want to learn some Git commands to get conformable with, this is the place to git gud! Here are some Git commands to get started that reflects to GitHub Desktop and will help you get started getting into the habit of using in the terminal! This list will go in order based on starting to somewhat finishing the task/project. I will also reference Hollow Knight: Silksong if you are a visual learner as well.
Note: This is based on my experience when learning Git Commands after moving away from the GitHub Desktop. If there is something I forgot to mention or any information that needs to be updated, let me know!
1. git init
If you are starting a new project, this is the first command you should do! Even if you have an existing project, but git isn't initialize, then it would be best to run this command!
Think of this as starting up a new game in Hollow Knight: Silksong. Starting up the game gives you more features to work with, which we will get into a bit.
Note: If you are cloning an existing project from GitHub that is already have git initialized, no need to do this command. You can if you want, but it would make no sense.
2. git clone url
Speaking of existing projects, if you want to grab an existing project and have it on your computer, this is the command!
For example, if you want to clone the Forem (dev.to) repository, you would clone via website url here:
More Specifically, copy the HTTPS link:
Then, in your VScode terminal, you would do:
git clone https://github.com/forem/forem.git
Think of this as you are opening up an existing file in the game. Simple as that.
If you are grabbing someone else's file and importing to your own machine, I would think of it as assuming they have everything installed. If the file is outdated, you will have to update it. For programming terms, if they don't have git, do git init.
Note: Make sure you are in an empty folder when cloning the repository.
3. git add filepath
Now you have a project and you make some changes in the project, like any other developer.
Before sending your changes to the branch on GitHub, you want to add the files you changed before doing the commit.
If you have change a lot of files and you want to include all of them in a commit, you would do:
git add .
However, if you want to include a specific file in a commit, you will have to find the file path. For example, if I change a file named tests.js and it lives in the app folder, it would be:
git add /app/tests.js
Extra Command to Know!
If you accidentally add all files to be tracked, you can revert by following the command to revert all files.
git restore .
For specific files, you would need the file path as usual.
git restore /app/tests.js
I would think of this as you play the game. Sometimes you equip charms, which I treat it as "Tracked files" where you have an inventory of items (untracked files). The equip items is what you want to use, while the inventory is the list of things you have collected/modified so far.
4. git commit -m "Hollow Purple"
Once you added the files based on the previous command, you are ready to commit! I treat this as a "checkpoint". It's like saving a game before you continue.
In the event where something went completely wrong, you can go back to the previous commit. For example, you have 3 commits:
A --> B --> C (You are here)
If you want to go back to "B", you will need to find the hash for Commit "B" and revert the commit by doing the following:
# Find the commit hash
git log --oneline
# Revert a specific commit
git revert <commit-hash>
Just like in the game, you can go back to your previous save point.
Pro Tip: Always make sure to fill out the commit message of what you did. It's best practice to say something like
git commit -m "Fix a rerouting bug"than sayinggit commit -m "Update file".
5. git push origin main
At this point, you have a lot of commits and changes. It's time to push it to the GitHub repository! This would be the command to do so!
However, it is best practice to fetch the changes that are on GitHub by doing the following:
git fetch origin main
Sometimes, if there were changes in the repository, but is not up-to-date in your local dev environment, then you would do the following after fetching:
git pull origin main
I would treat this as the version of the game. If the game is outdated, you would "fetch" the latest version and update the version from there. That way, the game will save properly. If you have a save data that is not align with the current version of the game, it will may likely lead to conflicts, which we would not cover since we are covering the basics.
6. Creating/Switching Branches
If you want to create a branch:
git branch nameBranch
To switch to that branch and work on the developments there:
git switch existingBranch
Pro Tip: If you want a single command where it creates the branch and switching it at the same time, use the following command below. Discovery based on @inayi comment!
git checkout -b branchName
7. git status
The main thing it will show you are the files that are tracked and not tracked. The ones that are tracked is the ones is going to be commit. The untracked files are the ones that are changed, but is not part of the upcoming commit. This command provides information to help you keep track on which files are changed and which files are going to be part of the commit.
That is it. It's not perfect and there is a GOOD chance I am missing something, but it is at least a good start on moving away from using GitHub Desktop and getting into the habit of learning these commands. Of course, there is many more I did not cover such as the git merge and all, but I want to keep it simple. Besides, this is based on my experience and the commands I use frequently that is mentioned in this article.
If you would like to learn more about git, check out the official documentation here: https://git-scm.com/docs
If you want a fun version to learn git (Discovery based on @thegm26 comment), check out the game here: https://ohmygit.org
That is only if you want to...
or be doomed.
Speaking of Doom, new trailer for Doomsday is here and it's just Doom Aura Farming lol.
Special Request to the Reader before Commenting!
If there are other commands that are good to know, feel free to leave a comment while having this image as part of your comment! (see below). If you are stopping by, I would love to see just the image of Hornet saying "Git Gud!". Though I would recommend adding something WITH the image because it has been reported where comments get deleted if you were to just send an image and nothing else...or you can find the image of Hornet saying "Git Gud" on the internet and use that instead.













Top comments (58)
Dude, I'm the same way. I switched to git because I was genuinely tired of clicking icons.
cuz
I'M A LINUX GEEK
I've grown to love the terminal. By the way, what does Silksong have to do with it?
HORNET IS GORGEOUS
ps make it full screen
Holy ASCII. That neat! I can't do CLI for anything because I like clicking apps lol. Though, it is nice to learn tbf. Great artwork btw. How u do that?
There's a cool site. It has nsf.. too... ahem, ahem.
A great ASCII art site. On a variety of topics. You can draw.
emojicombos.com
I've got some shortcuts like
gcforgit commit, andgclforgit cloneFor that, on Linux into
~/.bash_aliasesput :Quite Useful Thomas! I...
this when I was exploring git at some point. (Don't boo at me lol).
me after reading this post:
This is great post idea, Francis! 🤩 You inspired me, I'll write follow-up next week!
Thank Sylwia! Looking forward to it!!
It's always fun to learn a new git command <3
I have been using it since 3 years and everytime I make a mistake with my branch there is always a command to fix it !!
The best tool ever made by mankind LoL
Definetly. Thanks Risabh and
These are some of the git commands I frequently use. First:
Then it will print out something like this:
It is easier for me than
git logsince I sometimes I only want the overview of where am I at or sometimes when I messed something up and just want to go to particular commit hash.Second, sometimes the file you want to specifically add is nested way too deep and some of the folder/file names are long like this:
It got to a point that it was tiring for me so I tried pressing
Tabaccidentally I was surprised. It autocompletes if the first few letters is unique inside that directory. It made my life so easier and now I'm addicted to committing files that only covers my commit message.Last, which I think should be included in the basics for
gitwould be this:This is essentially pushing your branch towards a certain online repo's branch.
The
-ustands for upstream. It tells your local device to remember the last time where you push this code. So when you want to add more code in your branch you just do this instead:The
originis like the shortened term for a the repo link (which I think should also be essential in linking your local repo with the online repo):Then the
mainone is the branch where you want to drop off your code. But usually I won't suggest that. I would just simply use a different one:Essentially, this copies whatever branch you are in and pushes it onto the online repo without touching the main branch first.
I think I've explained some of the concepts horribly. I apologize in advance when something is inaccurate. But yeah, mistakes happen. Happy to learn more to
git gud.Thanks for the detail share Elmar! When I have time, will edit the article based on your suggestions! :D
Thanks for the article!
You can add also as a reference this game to get used to more neat git terms / concepts
ohmygit.org/
ooooo interesting. Will add it to this article. Thanks George!
Cool 😎, and your examples here funny too
Thanks man :D
The UI vs CLI framing is a good way to introduce Git, but there is one conceptual shift that makes Git much easier to understand: don't think of
git addas “tracking files.” Think of it as building the exact snapshot you want the next commit to contain.That distinction becomes important pretty quickly.
git restore .does not undo agit add .in the way many beginners expect; it restores working-tree files. For removing something from the staging area,git restore --staged <file>is the safer mental model.Once you understand the three states — working tree, staging area, and commit history — Git stops feeling like a collection of commands and starts behaving like a predictable state machine.
git statusis probably the most valuable command to build the habit around.Some comments may only be visible to logged-in visitors. Sign in to view all comments.