Git Commands Every Developer Should Know: A Practical Guide for Beginners

Git is one of the most important tools in modern software development.

Whether you're building a personal project, working with a development team, or contributing to an open-source project, Git helps you track changes, manage your code, and collaborate safely.

If you're new to Git, the number of commands can feel overwhelming.

You don't need to memorize hundreds of commands.

You need to understand the core Git workflow and become comfortable with the commands you will use regularly.

The Basic Git Workflow

The most common Git workflow looks like this:

The most common commands involved are:

git status
git add
git commit
git push

These four commands are used constantly in everyday development.

1. Check Whether Git Is Installed

Before using Git, check whether it is installed on your computer.

git --version

You should see a version similar to:

git version 2.x.x

The exact version depends on your installation.

If Git is not installed, install it using the official Git distribution for your operating system.

2. Configure Your Git Identity

Git uses your name and email address to associate commits with an author.

Set your name:

git config --global user.name "Your Name"

Set your email:

git config --global user.email "you@example.com"

Check your configuration:

git config --global --list

Use an email address that you are comfortable associating with your development commits.

If you're using GitHub, you can also configure Git to use an appropriate GitHub-associated email address.

3. Create a New Git Repository

If you already have a project on your computer and want Git to start tracking it, move into the project directory.

cd my-project

Then initialize Git:

git init

Git creates a hidden .git directory containing the repository's version-control information.

Your project now has a local Git repository.

my-project/
├── src/
├── public/
├── package.json
└── .git/

4. Check Repository Status

One of the most useful Git commands is:

git status

It tells you things such as:

• Which files have changed
• Which files are staged
• Which files are untracked
• Which branch you're currently using

For example:

On branch main

Changes not staged for commit:
  modified: src/app.js

Untracked files:
  notes.md

When you're unsure about the current state of your repository, start with:

git status

5. Add Files to the Staging Area

After changing your code, Git knows that files have changed, but those changes are not automatically included in your next commit.

Use:

git add filename

For example:

git add app.js

To stage multiple files:

git add app.js styles.css

To stage all current changes:

git add .

The staging area lets you decide which changes should be included in your next commit.

6. Understand the Staging Area

A useful way to understand Git is:

Suppose you changed three files:

app.js
styles.css
README.md

You might stage only the code changes:

git add app.js styles.css

Then create a commit.

The README changes remain outside that commit.

This gives you more control over your project's history.

7. Create a Commit

Once your changes are staged, create a commit:

git commit -m "Add user authentication"

A commit is a saved point in your project's history.

Good commit messages describe what changed.

Better Examples

git commit -m "Add responsive navigation"

git commit -m "Fix login form validation"

git commit -m "Add job search filters"

Avoid vague messages such as:

git commit -m "changes"

or:

git commit -m "update"

A useful commit message makes your project history easier to understand.

8. View Commit History

To view recent commits:

git log

For a shorter version:

git log --oneline

You may see something like:

a83f21d Add responsive navigation
71bc921 Fix login validation
4a91e20 Create project structure

The short commit ID can be useful when working with Git history.

9. Connect Your Local Repository to GitHub

Git and GitHub are related, but they are not the same thing.

Git is the version-control system.

GitHub is a platform that hosts Git repositories and provides collaboration features.

After creating a repository on GitHub, connect your local project to it.

For example:

git remote add origin https://github.com/username/my-project.git

Check the remote:

git remote -v

You should see your GitHub repository listed.

10. Push Your Code to GitHub

After committing your changes, push them to the remote repository.

git push origin main

This sends your local commits to GitHub.

The general workflow becomes:

This is one of the most important workflows to understand as a developer.

11. Clone an Existing Repository

If a project already exists on GitHub and you want a local copy, use:

git clone https://github.com/username/project.git

Then move into the project:

cd project

You now have a local copy of the repository.

A common workflow when joining a project is:

12. Create a Branch

Branches allow you to work on changes without modifying the main development line directly.

Create a branch:

git branch feature/login

Switch to it:

git switch feature/login

Or create and switch in one command:

git switch -c feature/login

Now your work is happening on the new branch.

13. Check Your Current Branch

Use:

git branch

The current branch is usually marked with an asterisk.

For example:

* feature/login
  main

You can also use:

git status

to see your current branch.

14. Switch Between Branches

To switch to another branch:

git switch main

To switch back:

git switch feature/login

Before switching branches, make sure you understand what will happen to your current uncommitted changes.

15. Merge a Branch

Suppose you've finished working on a feature branch.

First switch to the branch that should receive the changes:

git switch main

Then merge:

git merge feature/login

Git attempts to combine the changes from the feature branch into main.

A simplified workflow is:

In team environments, merging is often handled through Pull Requests.

16. Pull Changes From GitHub

Before starting work, you may need the latest changes from the remote repository.

Use:

git pull

A common workflow is:

git switch main
git pull

Then create your feature branch:

git switch -c feature/new-feature

This helps you start from an updated version of the project.

17. Fetch Remote Changes

Another useful command is:

git fetch

Fetching retrieves information about remote changes without automatically merging those changes into your current branch.

The difference is:

git fetch
→ Download information about remote changes

git pull
→ Fetch and integrate remote changes

18. See What Changed

To see unstaged changes:

git diff

To see staged changes:

git diff --staged

These commands are useful before committing.

A simple workflow is:

This gives you an opportunity to catch accidental changes before they become part of your project history.

19. Temporarily Save Work With Git Stash

Sometimes you have unfinished changes but need to switch branches.

You can temporarily store them:

git stash

Your working directory becomes clean.

Later, restore the changes:

git stash pop

A typical situation is:

20. Remove a File From Staging

Suppose you accidentally staged a file:

git add secrets.txt

You can remove it from the staging area with:

git restore --staged secrets.txt

The file remains in your working directory, but it is no longer staged for the next commit.

21. Discard Local Changes Carefully

If you want to restore a file to its last committed version:

git restore filename

For example:

git restore app.js

This can permanently discard uncommitted changes in that file.

22. Rename a File With Git

You can rename a tracked file using:

git mv old-name.js new-name.js

Then commit the change:

git commit -m "Rename user service file"

23. Delete a Tracked File

To remove a tracked file:

git rm old-file.js

Then commit:

git commit -m "Remove unused file"

24. Use a .gitignore File

Not every file should be committed to Git.

Common examples include:

• Dependency folders
• Build output
• Local environment files
• Temporary files
• Operating-system files
• Editor-specific files

A typical .gitignore might include:

node_modules/
dist/
build/
.env
.DS_Store

The exact contents depend on your project.

25. Understand Pull Requests

A Pull Request, commonly called a PR, is a way to propose changes to a repository.

A typical team workflow looks like:

A good Pull Request should explain:

• What changed
• Why it changed
• How it was implemented
• How it was tested
• Anything reviewers should know

Keep Pull Requests focused when possible.

26. Resolve Merge Conflicts

Sometimes Git cannot automatically combine changes.

You may see a merge conflict like:

<<<<<<< HEAD
const title = "Developer";
=======
const title = "Frontend Developer";
>>>>>>> feature/profile

The conflict markers show the competing changes.

You need to decide which version should remain.

After resolving the file:

git add filename

Then complete the merge or commit process as required.

27. View Remote Repositories

To see configured remote repositories:

git remote -v

You might see:

origin  https://github.com/username/project.git (fetch)
origin  https://github.com/username/project.git (push)

The name origin is a common default name for the main remote repository.

28. Create a New Branch From the Latest Main Branch

Before starting a new feature, a common workflow is:

git switch main
git pull
git switch -c feature/dashboard

Now your new branch starts from the latest local main.

This is a simple habit that can prevent many avoidable integration problems.

29. A Practical Daily Git Workflow

For many developers, a normal work session might look like this:

Start the Day

git switch main
git pull

Create a Feature Branch

git switch -c feature/user-profile

Work on the Feature

Modify your files.

Check Changes

git status
git diff

Stage Changes

git add .

Review Staged Changes

git diff --staged

Commit

git commit -m "Add user profile page"

Push

git push -u origin feature/user-profile

Create a Pull Request

Open the Pull Request on your Git hosting platform and describe the changes.

30. The Most Important Git Commands

If you're a beginner, focus on these first:

You don't need to memorize all of them on your first day.

Use them repeatedly and they will become familiar.

31. Git Commands Cheat Sheet

Keep this quick reference available while learning.

# Check Git version
git --version

# Configure your identity
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Create repository
git init

# Clone repository
git clone <repository-url>

# Check status
git status

# Stage one file
git add filename

# Stage everything
git add .

# Commit changes
git commit -m "Describe the change"

# View history
git log

# Short history
git log --oneline

# Create and switch branch
git switch -c feature-name

# Switch branch
git switch main

# Merge branch
git merge feature-name

# Pull remote changes
git pull

# Fetch remote information
git fetch

# Push changes
git push

# Push a new branch
git push -u origin feature-name

# View remotes
git remote -v

# View changes
git diff

# View staged changes
git diff --staged

# Temporarily save changes
git stash

# Restore stashed changes
git stash pop

32. Git vs GitHub

These two names are often confused.

Git

Git is a distributed version-control system.

It runs on your computer and tracks changes to your project.

GitHub

GitHub is an online platform that hosts Git repositories and provides collaboration features.

Think of it like this:

You can use Git without GitHub.

You can also use other platforms that host Git repositories.

33. What Beginners Should Avoid

1. Committing Everything Without Checking

Don't blindly run:

git add .
git commit -m "update"

Check your changes first.

Use:

git status
git diff

2. Huge Commits

A commit containing weeks of unrelated changes is difficult to understand.

Prefer smaller, meaningful commits.

3. Poor Commit Messages

Avoid:

update
changes
final
test
abc

Prefer:

Add password validation
Fix mobile navigation
Update job search filters
Add API error handling

4. Committing Secrets

Never commit:

API keys
Passwords
Private credentials
Database secrets
Access tokens

Use environment variables and appropriate secret-management practices instead.

5. Working Directly on Main

For collaborative projects, feature branches are often safer.

Use a workflow such as:

34. A Simple Git Learning Plan

If you're completely new to Git, don't try to learn everything in one day.

Stage 1 — Basic Workflow

Learn:

git init
git status
git add
git commit
git log

Stage 2 — GitHub

Learn:

git clone
git remote
git push
git pull

Stage 3 — Branching

Learn:

git branch
git switch
git merge

Stage 4 — Working Safely

Learn:

git diff
git restore
git stash
git fetch

Stage 5 — Team Collaboration

Learn:

• Pull Requests
• Code reviews
• Merge conflicts
• Branch strategies
• Commit conventions

This progression gives you a practical path without overwhelming you.

35. The Git Mental Model

The easiest way to remember Git is to think about the different stages of your work.

When you need changes from others:

Once this mental model becomes clear, individual Git commands become much easier to understand.

Final Thoughts

Git may seem complicated when you first encounter it.

You don't need to master every command.

Start with the core workflow:

Check → Stage → Commit → Push

Then gradually learn:

Branch → Switch → Pull → Merge → Review

The more you use Git on real projects, the more natural it becomes.

Quick Checklist

• Install Git
• Configure your Git identity
• Create a repository
• Understand git status
• Stage changes with git add
• Create commits with git commit
• Read history with git log
• Connect a repository to GitHub
• Push code to GitHub
• Clone repositories
• Create feature branches
• Switch between branches
• Merge changes
• Pull updates
• Understand Pull Requests
• Resolve merge conflicts
• Use .gitignore
• Never commit secrets
• Review changes before committing

Check → Stage → Commit → Push → Collaborate.