Git is everywhere in modern technology.

Developers use it to manage source code. DevOps engineers use it in CI/CD pipelines. System engineers use it to maintain configuration files and infrastructure code. Even project managers can benefit from understanding Git because much of modern software delivery depends on it.

But for beginners, Git can feel confusing.

You may see commands like commit, branch, push, pull, and merge and wonder:

"What is Git actually doing?"

This three-part series is designed to answer that question step by step.

In this first part, we will focus on the fundamentals and learn how to create a change, commit it, and send it to GitHub.

1. What Is Git?

Git is a version control system.

In simple terms, Git keeps a history of changes made to your project.

Imagine you are working on a configuration file.

Today:

server configuration v1

Tomorrow:

server configuration v2

Next week:

server configuration v3

Without version control, tracking those changes can become difficult.

Git allows you to record those changes as commits:

v1
 ↓
v2
 ↓
v3

You can inspect what changed, when it changed, and who made the change.

More importantly, you can often recover previous versions when something goes wrong.

2. Git vs GitHub

One of the first things beginners should understand is that Git and GitHub are not the same thing.

Git is the version control system.

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

A simple way to visualize it:

Your Computer
     │
     │ Git
     ▼
Local Repository
     │
     │ Push
     ▼
GitHub Repository

Git can work without GitHub.

You can use Git with other platforms such as GitLab or Bitbucket, or even use Git completely locally.

3. Why Learn Git Commands When GUI Tools Exist?

You may already use:

• GitHub Desktop

• VS Code Source Control

• GitKraken

• Sourcetree

• IntelliJ

• Another Git GUI

And that's perfectly fine.

In fact, GUI tools are excellent for visualizing branches, commits, and changes.

But underneath the GUI, Git is still doing the work.

For example:

GUI: Click "Commit"
        ↓
Git: git commit

GUI: Click "Push"
        ↓
Git: git push

GUI: Click "Create Branch"
        ↓
Git: git branch / git switch

Learning the command line gives you another level of understanding.

It becomes especially useful when working with:

• Linux servers

• Docker

• CI/CD

• GitHub Actions

• Cloud infrastructure

• Remote servers

• Troubleshooting

• Automation

You don't have to choose between GUI and command line.

Use the GUI when it helps you visualize things, and use the command line when it gives you speed, control, or better troubleshooting capabilities.

4. The Git Mental Model

Before learning commands, understand this concept.

Git has several important stages:

Working Directory
       │
       │ git add
       ▼
Staging Area
       │
       │ git commit
       ▼
Local Repository
       │
       │ git push
       ▼
Remote Repository
       │
       ▼
     GitHub

This is probably the most important diagram in Part 1.

Let's understand it.

Working Directory

This is where you actually edit your files.

For example:

my-project/
├── README.md
├── app.py
└── config.yml

You change config.yml.

The file is now modified in your working directory.

Staging Area

You decide that the change should be included in your next commit.

You run:

git add config.yml

Now the change is staged.

Think of the staging area as:

"These are the changes I want to include in my next snapshot."

Local Repository

You create a commit:

git commit -m "update server configuration"

Now Git records the change in your local repository.

Remote Repository

Finally:

git push

The commit is sent to the remote repository, such as GitHub.

5. Check Your Git Installation

Let's start from the beginning.

Open your terminal and run:

git --version

You should see something similar to:

git version 2.x.x

This confirms that Git is installed.

6. Configure Your Git Identity

Git records information about who created each commit.

You can configure your global identity:

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

Check it:

git config --global user.name
git config --global user.email

You might see:

Your Name
you@example.com

Repository-Specific Git Identity

There is an important feature that is especially useful if you have multiple Git accounts.

You can configure Git only for the current repository.

Go into your project:

cd my-project

Then:

git config user.name "Your Name"
git config user.email "you@example.com"

Notice that we removed --global.

This configuration applies only to this repository.

This is useful when you have, for example:

Personal GitHub account
        +
Company GitHub account

and don't want to change your global Git configuration every time.

7. Clone a GitHub Repository

Most beginners will encounter Git by cloning an existing project.

For example:

git clone git@github.com:username/my-project.git

Then:

cd my-project

You now have a local copy of the repository.

You can check the remote connection:

git remote -v

You might see:

origin  git@github.com:username/my-project.git (fetch)
origin  git@github.com:username/my-project.git (push)

Here, origin is simply the conventional name for the remote repository.

8. git status — Your Best Friend

If you learn only one Git command today, make it:

git status

It tells you what's happening in your repository.

For example:

On branch master

nothing to commit, working tree clean

This means:

• You are on the master branch.

• You have no uncommitted changes.

• Your working directory is clean.

Now imagine you modify README.md.

Run:

git status

Git may show:

Changes not staged for commit:
    modified: README.md

Git is essentially telling you:

"You changed this file, but you haven't prepared it for a commit yet."

This is why experienced Git users frequently run:

git status

when they're unsure what to do next.

9. git add — Prepare Your Changes

Suppose you modified:

README.md

You want to include this change in your next commit.

Run:

git add README.md

Then check:

git status

You should now see something similar to:

Changes to be committed:
    modified: README.md

The change is now in the staging area.

Remember:

git add
    ↓
Stage the change

git commit
    ↓
Record the change

git add does not create a commit.

Add Multiple Files

You can stage multiple files:

git add file1.txt file2.txt

Or stage changes in the current directory:

git add .

For beginners, git add . is convenient, but always check git status before committing so you know exactly what you're about to include.

10. git commit — Create a Snapshot

Once your changes are staged:

git commit -m "update README"

Git creates a commit.

You might see:

[master a1b2c3d] update README
 1 file changed

The value:

a1b2c3d

is part of the commit's unique identifier.

A commit is essentially a recorded snapshot of your project at a particular point in time.

11. Write Useful Commit Messages

A commit message should explain what changed.

Good examples:

add server monitoring configuration
fix database connection timeout
update deployment documentation
add health check endpoint

Avoid messages like:

update
changes
fix
test
done

Imagine looking at your Git history six months later.

Which one would help you understand what happened?

update

or:

fix database connection timeout

Exactly.

Good commit messages become part of your project's technical history.

12. git log — Understand Your History

After creating commits, you can see the history with:

git log

For a shorter version:

git log --oneline

Example:

a1b2c3d update README
f4e5d6c add deployment documentation
123abcd initial commit

This is one of the easiest ways to understand how your project has evolved.

A More Visual History

You can use:

git log --oneline --decorate --graph

Example:

* a1b2c3d update README
* f4e5d6c add deployment documentation
* 123abcd initial commit

Later, when we start working with branches, this command becomes extremely useful because it can show how different branches diverged and merged.

13. git show — What Exactly Changed?

Suppose you see:

a1b2c3d update README

You can inspect the commit:

git show a1b2c3d

Git will show information about the commit and the changes it introduced.

This is useful when someone asks:

"What exactly changed in that commit?"

Instead of opening every file manually, Git can show you the answer.

14. git diff — What Have I Changed?

Another extremely useful command is:

git diff

Suppose you modify:

config.yml

before committing, run:

git diff

Git shows you the difference between the current file and the last committed version.

Think of it as:

"Show me what I changed."

This is a great habit before committing.

15. git push — Send Your Commit to GitHub

So far, your commit exists locally.

To send it to GitHub:

git push

Or explicitly:

git push origin master

The basic flow is:

Your Computer
     │
     │ git commit
     ▼
Local Git Repository
     │
     │ git push
     ▼
GitHub

This distinction is important.

A commit does not automatically mean that the change is on GitHub.

You can have:

Local:
3 commits

GitHub:
1 commit

until you push.

16. git pull — Get Changes From GitHub

Now imagine another developer pushed a change to GitHub.

Your local repository doesn't automatically know about the latest files.

You can run:

git pull

This retrieves the latest changes and integrates them into your current branch.

The basic idea is:

GitHub
   │
   │ git pull
   ▼
Your Local Repository

A common daily workflow is therefore:

git pull

# Work on your files

git status

git add .

git commit -m "describe the change"

git push

17. git fetch — Check Remote Changes First

There is another useful command:

git fetch

It retrieves information about changes from the remote repository without immediately integrating those changes into your current branch.

This makes it useful when you want to inspect what's happening before deciding what to do.

A simplified comparison:

git fetch
    ↓
Get remote information
    ↓
Inspect
    ↓
Decide what to do

while:

git pull
    ↓
Get remote changes
    ↓
Integrate them

As you become more experienced with Git, you'll use fetch more often for controlled workflows and troubleshooting.

18. A Complete Git Workflow

Let's put everything together.

Imagine you cloned a project:

git clone git@github.com:username/my-project.git
cd my-project

First:

git status

You modify:

README.md

Check what changed:

git diff

Stage it:

git add README.md

Check again:

git status

Create the commit:

git commit -m "update README"

Check history:

git log --oneline

Finally:

git push

The complete workflow:

Clone
  ↓
Edit
  ↓
git status
  ↓
git diff
  ↓
git add
  ↓
git commit
  ↓
git log
  ↓
git push

That's Git fundamentals.

19. How This Looks in a GUI

If you're a GUI user, the same workflow might look like:

Edit File
    ↓
Source Control detects changes
    ↓
Select files
    ↓
Stage
    ↓
Write commit message
    ↓
Commit
    ↓
Push

The command-line equivalent is:

git status
git diff
git add .
git commit -m "your message"
git push

The GUI isn't doing something fundamentally different.

It's providing a visual interface to Git operations.

Once you understand the commands, many GUI buttons suddenly become much easier to understand.

20. The Five Commands to Master First

Don't try to memorize every Git command.

Start with these five:

git status
git add
git commit
git log
git push

And add these shortly afterward:

git pull
git fetch
git diff
git show

If you can comfortably use these commands, you already have a solid Git foundation.

Final Thoughts

Git can look complicated when you first see dozens of commands.

But the core concept is actually simple:

I changed something
       ↓
git status
       ↓
git diff
       ↓
git add
       ↓
git commit
       ↓
git push

The most important thing isn't memorizing commands.

It's understanding where your changes currently exist:

Working Directory
       ↓
Staging Area
       ↓
Local Repository
       ↓
Remote Repository

Once this mental model becomes clear, Git becomes much less mysterious.

And this is only the beginning.

In Part 2, we'll move from individual work to team collaboration and learn the concepts that make Git truly powerful:

Branches, git switch, git stash, git merge, git merge --squash and working with remote branches.

That's where Git starts getting really interesting.