Git is one of the most important tools in modern software development. Whether you're working alone, contributing to an open-source project, or collaborating with a large engineering team, Git helps you track changes, experiment safely, and coordinate work without overwriting someone else's code.
But Git can feel confusing at first. There are hundreds of commands, flags, and workflows out there the good news is you don't need to memorize all of them to work effectively. Most daily development tasks can be handled with a small, well-understood set of commands.
In this article, we'll walk through 10 Git commands every developer should master, with practical examples and the common mistakes to avoid with each one.
A Typical Git Workflow
Before looking at each command individually, here's the core loop you'll repeat constantly:
Edit files
↓
git status
↓
git add
↓
git commit
↓
git pull
↓
git push
You inspect your changes, stage the files you want to save, create a commit, sync with the remote repository, and push your work. Branches let you run this entire loop on a copy of the codebase, so you never touch the main branch directly until your work is reviewed and ready.
The 10 commands below cover everything in that loop plus the two you need before it even starts: git init and git clone.
1. git init
What it does: Creates a new Git repository in the current directory. It adds a hidden .git folder that stores the repository's history, branches, configuration, and everything else Git needs to track your project.
Syntax:
git init
Example:
mkdir task-manager
cd task-manager
git init
Git now tracks everything inside task-manager. Confirm it worked with git status.
Common mistake: Running git init in the wrong folder creates an unintended repository. Check your current directory first with pwd (or cd alone on Windows Command Prompt). Also avoid initializing a repository inside another Git repository unless you specifically need nested repos or submodules.
2. git clone
What it does: Downloads an existing remote repository to your machine project files, commit history, branch information, and remote configuration, all in one step.
Syntax:
git clone <repository-url>
Example:
git clone https://github.com/example/task-manager.git
Git creates a task-manager directory and downloads the project into it. To use a different local folder name:
git clone https://github.com/example/task-manager.git project
Common mistake: Running git init after cloning unnecessary, since a cloned project is already a repository. The other classic slip: cloning and forgetting to cd into the new directory before making changes.
3. git status
What it does: Shows the current state of your working directory and staging area your branch, modified files, staged files, untracked files, and whether you're ahead of or behind the remote.
Syntax:
git status
Example output:
Changes not staged for commit:
modified: src/app.js
Untracked files:
src/utils.js
This tells you app.js has changed and utils.js hasn't been added to Git yet. For a shorter view:
git status --short
M src/app.js
?? src/utils.js
Common mistake: Committing without checking what's actually staged. Run git status before every commit it's the single habit that prevents accidental secrets, unrelated changes, or environment files from sneaking into your history.
4. git add
What it does: Moves changes into the staging area, letting you choose exactly what goes into your next commit.
Syntax:
git add <file> # one file
git add file1 file2 # multiple files
git add . # everything
Example:
git add src/app.js
git status # verify what's staged
Common mistake: Running git add . without reviewing changes first can stage files you never meant to commit. Always check git status beforehand, and keep a .gitignore for things that should never be tracked:
node_modules/
.env
dist/
coverage/
Never commit passwords, API keys, certificates, or production credentials a .gitignore entry doesn't undo a mistake once something's already been committed and pushed.
5. git commit
What it does: Saves your staged changes as a new point in the repository's history. Each commit should represent one logical, self-contained change.
Syntax:
git commit -m "Commit message"
Good examples:
git commit -m "Fix validation for empty email field"
git commit -m "Add pagination to orders table"
git commit -m "Refactor payment service error handling"
Common mistake: Vague messages like "update", "changes", or "fix" tell future-you (and your reviewers) nothing. The other frequent issue: bundling several unrelated changes into one commit. Keep commits focused it makes them easier to review, revert, and understand months later.
6. git branch
What it does: Lets you view, create, rename, and delete branches the mechanism that lets you work on a feature or fix without touching the main branch directly.
Syntax:
git branch # list branches
git branch <branch-name> # create a branch
git branch -d <branch-name> # delete a merged branch
Example:
git branch feature/user-profile
git branch
* main
feature/user-profile
The asterisk marks your current branch.
Common mistake: Creating a branch doesn't switch you to it running git branch feature/user-profile leaves you right where you were. You need git switch for that (next command). Also, use descriptive branch names feature/user-profile or fix/payment-validation, not new-branch or test.
7. git switch
What it does: Changes your current branch and can create a new one and switch to it in a single command.
Syntax:
git switch <branch-name> # switch to an existing branch
git switch -c <branch-name> # create and switch in one step
Example:
git switch -c feature/user-profile
This creates feature/user-profile and switches to it immediately. Return to main with:
git switch main
Common mistake: Starting work without checking which branch is active always a risk of accidentally committing straight to main. Run git branch or git status before you start editing. You'll also see older tutorials use git checkout -b feature/user-profile, which still works, but git switch is the clearer, purpose-built command for this job.
8. git pull
What it does: Retrieves changes from a remote repository and integrates them into your current branch. Under a common configuration, it's effectively git fetch + git merge in one step.
Syntax:
git pull
git pull origin main # explicit remote and branch
Example:
git switch main
git pull origin main
On a feature branch, some teams prefer rebasing incoming changes instead of merging:
git pull --rebase
Check your team's agreed convention before choosing between the two.
Common mistake: Pulling with uncommitted changes on your branch can trigger confusing conflicts check git status first, and commit, stash, or discard local changes as needed. Also double-check you're pulling into the branch you mean to pulling main while you think you're on a feature branch is a quick way to create an unexpected merge.
9. git push
What it does: Uploads your local commits to a remote repository like GitHub, GitLab, or Bitbucket.
Syntax:
git push <remote> <branch>
Example:
git push origin main
# push a new branch and link it to its remote counterpart
git push -u origin feature/user-profile
The -u flag sets the upstream branch after that, a plain git push is enough.
Common mistake: Casual use of git push --force. Force pushing rewrites remote history and can silently erase commits your teammates just pushed. When you genuinely need to rewrite your own branch's history, prefer:
git push --force-with-lease
It checks whether the remote branch changed since you last fetched before overwriting anything much safer, though you should still confirm your team's rules before force-pushing any shared branch.
10. git log
What it does: Displays the repository's commit history what changed, who changed it, when, and (crucially) which commit introduced a given feature or bug.
Syntax:
git log
git log --oneline
Example:
a81e5c2 Add user profile page
7d349af Fix authentication redirect
3ce2189 Initialize project
For a visual view of branches and merges:
git log --oneline --graph --decorate --all
To see the history of a single file:
git log -- src/app.js
Common mistake: Jumping straight into debugging unfamiliar code without checking its history first. A quick git log --oneline on the relevant file often shows you exactly when and sometimes why a problem was introduced, before you've touched a single line.
Putting It All Together
Here's the full loop as one realistic feature-branch workflow:
git switch main
git pull origin main
git switch -c feature/user-profile
Make your changes, then check what you've touched:
git status
Stage exactly what belongs in this commit:
git add src/profile.js
git add src/profile.test.js
Commit with a message that explains the why, not just the what:
git commit -m "Add editable user profile"
Sanity-check the history:
git log --oneline
Push the branch and open a pull request:
git push -u origin feature/user-profile
That's the entire lifecycle of a feature, start to finish, using only the 10 commands above.
Commands Worth Learning Next
Once these 10 feel automatic, this is the natural next layer:
git diff
git restore
git stash
git fetch
git merge
git rebase
git reset
git revert
git tag
git remote
Be especially careful with anything that rewrites or removes history git reset --hard, git clean, and force pushes chief among them. Always know what a command will do before you run it against work that matters.
Final Thoughts
You don't need to memorize every Git command to be productive. Start with the ones you'll use constantly:
git init · git clone · git status · git add · git commit · git branch · git switch · git pull · git push · git log
The real skill isn't typing commands quickly it's understanding the state of your repository before you change anything. Check your branch. Review what's modified. Stage changes deliberately. Write commit messages that mean something. Pull before you push. Don't rewrite shared history without a clear, communicated reason.
Once those habits become automatic, Git stops feeling like a tool you're afraid of breaking, and starts being one of the most useful parts of how you build software.
These AI-focused links are not closely related to “10 Git Commands Every Developer Should Master,” so avoid forcing them into the command sections. Add them at the end under Related Reading.
Related Reading
Git is only one part of the modern development workflow. AI is also changing how developers build applications, automate tasks, and collaborate. Explore these related guides:
- Learn how intelligent workflows reduce repetitive work in What Is AI Automation?.
- Discover how AI may reshape jobs, skills, and workplace productivity in AI and the Future of Work.
- Explore practical AI features transforming smartphone experiences in How AI Is Transforming Mobile Applications.
- Compare conventional workflows with AI-assisted approaches in AI-Driven Website Development vs Traditional Website Development.
Top comments (0)