8 Git Commands Every Developer Must Know (And It's Not Just 'add', 'commit', 'push') |

Hey readers,

I have a confession. Early in my career, before I truly understood version control, I “backed up” my code by copying the entire project folder and renaming it project_final_v2_really_final_this_time. One day, I accidentally overwrote the wrong folder and lost a full day’s work. I felt sick.

That’s the day I stopped using Git and started understanding it.

Many beginners learn just three commands: git add, git commit, and git push. While that’s a start, it’s like knowing how to only drive forward. To truly navigate the world of software development, you need to know how to turn, reverse, and even check your map.

Think of Git as a time machine for your code. It allows you to travel back to see previous versions, explore alternate futures, and merge different ideas together without fear. This guide covers the essential commands that will make you a confident time traveler.

1. `git clone` (Copying the Time Machine)

Before you can time travel, you need a time machine. git clone is the command you use to get a local copy of a remote repository (like one from GitHub).

Analogy: This is like going to the store and buying your own time machine, pre-loaded with all the history from the manufacturer.
How to use it: git clone <repository_url>
Why it matters: This is the starting point for contributing to any existing project. You clone the code to your machine so you can start working on it.

2. `git branch` (Creating an Alternate Timeline)

You should never make changes directly on your main master or main branch. Instead, you create a separate branch for every new feature or bug fix.

Analogy: A branch is an alternate timeline. It lets you experiment with a new idea (like “what if we added a dark mode?”) without affecting the main, stable history of your project.
How to use it: git branch <new_branch_name>
Why it matters: Branching is the core of collaborative development. It keeps your main codebase clean and allows multiple people to work on different features simultaneously without getting in each other’s way.

3. `git checkout` (Traveling Between Timelines)

Once you have multiple branches (timelines), you need a way to switch between them.

Analogy: This is the dial on your time machine that lets you jump from the “main timeline” to your “dark mode feature” timeline.
How to use it: git checkout <branch_name> (You can also use git checkout -b <new_branch_name> to create a new branch and switch to it in one command).
Why it matters: It allows you to context-switch. A teammate needs you to look at a bug? You can checkout their branch, inspect the code, and then checkout back to your own branch to continue your work.

4. `git merge` (Combining Timelines)

Once you’ve finished your feature in an alternate timeline and are happy with it, you need to bring it into your main timeline.

Analogy: git merge is the act of taking the successful outcome from your experimental timeline and making it the new reality in your main timeline.
How to use it: First, checkout to the branch you want to merge into (e.g., main), then run git merge <feature_branch_name>.
Why it matters: This is how features get added to the application. You build them in isolation on a branch, and then merge them into the main codebase when they are complete and tested.

5. `git pull` (Syncing with the Main Timeline)

If you’re working on a team, the main timeline (the remote main branch on GitHub) is constantly changing as other developers merge their features. git pull updates your local branch with all the changes from the remote.

Analogy: Before you show your new invention to the world, you check to see if anyone else has made new discoveries that might affect your work.
How to use it: git pull origin main
Why it matters: Pulling frequently prevents your branch from diverging too far from the main branch, which makes merging much easier and avoids nasty conflicts.

6. `git log` (Reviewing Your Travel History)

git log shows you a history of all the commits (snapshots in time) for your current branch.

Analogy: This is the logbook of your time machine, showing every trip you’ve ever taken, who authorized it, and what changes were made.
How to use it: git log (You can use git log --oneline for a more concise view).
Why it matters: It’s essential for understanding the history of a project. You can see who changed a file and when, which is invaluable for debugging.

7. `git reset` (Dangerous Time Travel)

Sometimes you make a mistake and want to undo a commit. git reset allows you to move the branch pointer back to a previous commit, effectively erasing the history.

Analogy: This is the dangerous kind of time travel where you go back and change the past. It can have unintended consequences.
How to use it: git reset --hard <commit_hash>
Why it matters: It’s a powerful tool for cleaning up your local history before you share it with others. Warning: Never use git reset on a branch that others are using, as it rewrites history and can cause chaos.

8. `git stash` (Putting Your Work in Your Pocket)

What if you’re in the middle of a change, but you need to switch branches to fix an urgent bug? You can’t commit your half-finished work. git stash temporarily saves your uncommitted changes.

Analogy: You’re working on a project, but have to run out. You sweep all your work into a drawer to deal with later. When you come back, you pull it all out and it’s exactly as you left it.
How to use it: git stash to save the changes, and git stash pop to re-apply them.
Why it matters: It’s a fantastic utility for keeping your working directory clean when you need to switch context quickly without committing incomplete code.

What’s the next move?

Challenge: Don’t just read, do. Open a project, create a new branch called test-feature, make a small change to a file, commit it, and then merge it back into your main branch. Get comfortable with the flow.

Mastering these commands will turn Git from a scary necessity into one of your most powerful tools.

Thanks for reading!

Bou~codes and Naima from 10xdev blog.