If you're starting your journey in software development, you've probably heard the word Git quite a lot.

Developers use Git every day to save their work, collaborate with teammates, experiment with new features, and keep track of what changed in a project.

At first, Git can feel confusing because there are quite a few commands to remember.

The good news?

You don't need to learn 50 Git commands to get started.

If you understand a handful of commands and how branches, merges, and conflicts work, you'll already be comfortable with most day-to-day Git tasks.

Let's break it down in simple terms.

What is Git?

Git is a version control system that helps you track changes in your code.

Think of it like having a detailed history of your project.

For example, imagine you're working on a website.

Today you add a login page.

Tomorrow you change the database configuration.

The next day you accidentally break something.

With Git, you can see what changed, who changed it, and when the change was made. You can also go back to an earlier version when necessary.

Git is especially useful when multiple developers are working on the same project.

1. Essential Git Commands Every Beginner Should Know

Let's start with the commands you'll probably use most often.

git init

This command creates a new Git repository in your project.

git init

For example:

mkdir my-project
cd my-project
git init

Git will create a hidden .git directory inside your project.

This .git directory contains the information Git needs to track your project.

When would you use it?

Usually when you're starting a new project and want Git to manage it.

2. git clone

If a project already exists on GitHub, GitLab, Bitbucket, or another Git server, you don't need to create a repository from scratch.

You can clone it.

git clone https://github.com/example/my-project.git

This downloads the repository to your computer.

After cloning:

cd my-project

You're ready to start working.

Simple way to remember it

git clone = Download an existing Git repository

3. git status

This is one of the commands you'll use constantly.

git status

It tells you what's happening in your repository.

For example, Git might tell you:

modified: app.py
untracked: config.yml

This means:

• app.py was changed
• config.yml is a new file Git isn't tracking yet

Beginner tip

If you're ever confused about what's going on in your Git repository:

git status

is usually a good place to start.

4. git add

Before Git records your changes, you need to tell Git which changes you want to include.

For a specific file:

git add app.py

Or to add all changed files:

git add .

Think of git add as putting your changes into a staging area.

You aren't creating a permanent Git version yet.

You're basically saying:

"Git, these are the changes I want to include in my next commit."

5. git commit

Once your changes are staged, you can create a commit.

git commit -m "Add login functionality"

A commit is basically a saved checkpoint in your project history.

Good commit messages should explain what changed.

For example:

git commit -m "Fix login validation"

is much more useful than:

git commit -m "changes"

A good habit

Keep commits small and meaningful.

Instead of doing everything and creating one huge commit:

Updated everything

try creating commits such as:

Add user login page
Fix password validation
Add logout functionality
Update login API

This makes the project history much easier to understand.

6. git log

Want to see your project's history?

Use:

git log

You'll see previous commits, their authors, dates, and commit messages.

For a cleaner view:

git log --oneline

Example:

a82f1c2 Fix login validation
72b9a31 Add login page
51ce912 Create project structure

This is much easier to read when you're quickly checking history.

7. git diff

Sometimes you want to know exactly what changed in a file.

That's where git diff helps.

git diff

It shows the differences between your working files and the last committed version.

For example, you might see:

- print("Hello")
+ print("Hello World")

The - line was removed and the + line was added.

8. git branch

Now we get to one of the most important concepts in Git:

branches.

You can see your existing branches with:

git branch

For example:

* main
  development
  feature/login

The * shows the branch you're currently using.

What is a Git Branch?

Imagine your project has a main road.

That's your main branch.

Now you want to build a new feature.

Instead of making changes directly to the main road, you create a separate road where you can work safely.

That's essentially what a Git branch is.

For example:

main
  |
  |---- feature/login
  |
  |---- feature/payment

You can work on feature/login without affecting the main branch.

This is one of the reasons Git is so useful for development teams.

9. Creating a Branch

You can create a new branch using:

git branch feature/login

But creating it doesn't automatically switch you to it.

You can switch using:

git switch feature/login

Or create and switch to the branch in one command:

git switch -c feature/login

This is probably the command you'll use most often.

10. Switching Between Branches

To switch to another branch:

git switch main

Then:

git switch feature/login

Older Git workflows commonly use:

git checkout feature/login

git checkout is still widely seen in existing projects, but for beginners, git switch makes the intention clearer.

11. The Typical Git Workflow

A simple development workflow might look like this:

git switch -c feature/login

# Make your code changes

git status

git add .

git commit -m "Add login functionality"

Then you might push the branch to GitHub:

git push -u origin feature/login

After that, your team can review the changes through a Pull Request.

12. git push

A commit exists on your local computer.

It doesn't automatically appear on GitHub.

That's where git push comes in.

git push

It uploads your local commits to the remote repository.

For a new branch, you may use:

git push -u origin feature/login

After setting the upstream branch, future pushes can usually be done with:

git push

13. git pull

Now imagine another developer pushed changes to the remote repository.

You want those changes on your computer.

You can use:

git pull

Conceptually, it gets the latest remote changes and integrates them into your current branch.

A common workflow is:

git pull

before starting work, especially when working with a shared branch.

Branching, Merging and Conflicts

Now let's talk about the part of Git that often confuses beginners.

Merging.

Don't worry — the concept is actually pretty simple.

14. What is Git Merge?

Suppose you have:

main
  |
  A
  |
  B

You create a new branch:

main
  |
  A
  |
  B
  \
   C
   |
   D
feature/login

You finish your login feature.

Now you want those changes in main.

You can merge the feature branch into main.

First, switch to main:

git switch main

Then:

git merge feature/login

Git will combine the changes from feature/login into main.

15. A Real-World Example

Imagine you're working on an e-commerce application.

The project has:

main

You create:

feature/payment

You add:

• Stripe integration
• Payment validation
• Payment success page

You commit your work:

git add .
git commit -m "Add payment integration"

Then you switch back to main:

git switch main

And merge:

git merge feature/payment

Now the payment feature is part of the main branch.

16. What is a Merge Conflict?

Here's where things get interesting.

A merge conflict happens when Git can't automatically decide which change should be kept.

For example, imagine two developers change the same line.

Developer A changes:

message = "Hello"

to:

message = "Hello from Dev A"

Developer B changes the same line to:

message = "Hello from Dev B"

Now Git tries to merge the two branches.

Git essentially says:

"Both changes are valid, but I don't know which one you want."

That's a merge conflict.

17. What Does a Conflict Look Like?

Git may modify the file and show something like:

<<<<<<< HEAD
message = "Hello from Dev A"
=======
message = "Hello from Dev B"
>>>>>>> feature/login

These markers tell you where the conflict is.

What do they mean?

<<<<<<< HEAD

This represents the version from your current branch.

=======

Separates the two versions.

>>>>>>> feature/login

Represents the incoming branch's version.

18. How to Resolve a Merge Conflict

Don't panic when you see a conflict.

You need to manually decide what the final code should look like.

For example, you might decide that the correct version is:

message = "Hello from our application"

Remove the conflict markers:

<<<<<<<
=======
>>>>>>>

Save the file.

Then check:

git status

Git will tell you which files still have conflicts.

19. Stage the Resolved File

Once you've fixed the conflict:

git add app.py

This tells Git:

"I've resolved this conflict."

Then complete the merge:

git commit

Depending on the merge situation, Git may automatically prepare a merge commit message.

You can also provide your own message when appropriate:

git commit -m "Merge feature/login into main"

20. Complete Conflict Resolution Example

Here's the whole process.

You are on main:

git switch main

Merge another branch:

git merge feature/login

Git reports:

CONFLICT (content): Merge conflict in app.py

Check the status:

git status

Open app.py and resolve the conflicting section.

Then:

git add app.py

Finally:

git commit

And check:

git status

If everything is clean, your merge is complete.

21. What if You Don't Want to Continue the Merge?

Sometimes you start a merge and realize that you don't want to deal with it right now.

You can cancel the merge with:

git merge --abort

Git will attempt to return your working tree to the state it was in before the merge started.

This can be very useful when you're stuck.

22. Deleting a Branch

Once a feature has been merged and you no longer need the local branch:

git branch -d feature/login

To delete a remote branch:

git push origin --delete feature/login

Be careful with branch deletion if other developers still need the branch.

23. A Simple Git Workflow to Remember

If you're a beginner, don't try to memorize everything at once.

Start with this workflow:

# Get the latest code
git pull

# Create a feature branch
git switch -c feature/my-feature

# Check your changes
git status

# Stage changes
git add .

# Save changes
git commit -m "Add my feature"

# Push branch
git push -u origin feature/my-feature

Then create a Pull Request and let your team review the changes.

24. Git Commands Cheat Sheet

CommandWhat it doesgit initCreate a new Git repositorygit clone <url>Download an existing repositorygit statusCheck repository statusgit add <file>Stage a filegit add .Stage all changesgit commit -m "message"Create a commitgit logView commit historygit log --onelineView compact commit historygit diffView changesgit branchList branchesgit switch <branch>Switch branchesgit switch -c <branch>Create and switch to a branchgit merge <branch>Merge a branchgit pushUpload commitsgit pullGet and integrate remote changesgit merge --abortCancel an ongoing mergegit branch -d <branch>Delete a local branchFinal Thoughts

Git can look complicated when you first see commands like:

git rebase
git cherry-pick
git reset
git revert
git stash

Don't worry about learning all of them immediately.

Start with the basics:

clone
   ↓
status
   ↓
add
   ↓
commit
   ↓
push
   ↓
pull

Then understand:

branch → work → commit → merge → resolve conflicts

Once this workflow becomes natural, Git becomes much less intimidating.

The important thing isn't memorizing every command.

It's understanding what Git is doing and why you're running the command.

And honestly, even experienced developers occasionally run:

git status

just to remind themselves what's going on.

That's completely normal.