In Part 1, we learned the Git fundamentals:

Edit
  ↓
git status
  ↓
git add
  ↓
git commit
  ↓
git push

In Part 2, we learned how to work with a team:

Branch
  ↓
Develop
  ↓
Commit
  ↓
Push
  ↓
Merge

So far, everything sounds easy.

But real Git usage is not always this clean.

Eventually, you'll see a message like:

CONFLICT (content): Merge conflict

Or perhaps you'll accidentally reset a branch and think:

"Oh no... did I just lose my commit?"

This is where understanding Git becomes much more important than simply knowing commands.

In this final part, we'll learn how to investigate problems, resolve conflicts, understand history, and recover from mistakes.

1. Git Conflicts Are Normal

A Git conflict doesn't mean Git is broken.

It usually means:

Two people changed the same part of a file, and Git doesn't know which change should win.

For example, imagine the master branch contains:

server_port=8080

A developer changes it to:

server_port=9090

At the same time, another developer changes the same line to:

server_port=3000

Git cannot safely choose between them.

So when you merge the branches:

git merge feature/config

Git may stop and report a conflict.

2. Always Start With git status

When something unexpected happens, don't immediately start running random Git commands.

Start with:

git status

This is one of the best Git troubleshooting habits you can develop.

During a merge conflict, Git might tell you:

You have unmerged paths.

Unmerged paths:
    both modified: optimization.txt

Now you know exactly which file needs attention.

A simple troubleshooting mindset is:

Something went wrong
       ↓
git status
       ↓
Understand the current state
       ↓
Decide what to do

3. Understanding Conflict Markers

Open the conflicted file.

You may see:

<<<<<<< HEAD
no optimization from master
=======
Conflict test from branch
>>>>>>> feature/conflict

These markers divide the competing changes.

<<<<<<< HEAD
Your current branch
=======

Incoming branch
>>>>>>> feature/conflict

Git is effectively saying:

"I found two different versions. You need to decide what the final version should be."

4. Resolving a Conflict

Suppose you decide the final file should contain:

Master and feature optimization configuration

Edit the file and remove the conflict markers.

Then check:

git status

Stage the resolved file:

git add optimization.txt

Then complete the merge:

git commit -m "resolve optimization conflict"

The general process is:

Merge
  ↓
Conflict
  ↓
git status
  ↓
Open conflicted file
  ↓
Understand both changes
  ↓
Choose correct result
  ↓
Remove conflict markers
  ↓
git add
  ↓
git commit

5. Don't Resolve Conflicts Blindly

This is an important professional habit.

A conflict isn't simply a technical problem.

Sometimes the correct solution depends on the application's requirements.

For example:

Database timeout = 30 seconds

versus:

Database timeout = 60 seconds

Git cannot tell you which value is technically or business-wise correct.

You may need to ask:

• Why was the original value changed?

• Is the new value required?

• Is this configuration used in production?

• Does another service depend on it?

Git resolves text. Humans resolve intent.

6. Understand Your History With git log --graph

After branches and merges, a normal git log can become difficult to understand.

Use:

git log --oneline --decorate --graph

You might see:

*   638ec51 conflict resolved
|\
| * 307bc8c added from new branch
* | 0408aa2 updated from master
* | 74009ca added from master
|/
* 4ab0f8f added feature/system-optimization data

This visualization helps you understand:

• where branches were created

• where commits happened

• where branches diverged

• where they were merged

For anyone working seriously with Git, this is an extremely useful command.

7. git show — Investigate a Commit

Suppose you see:

638ec51 conflict resolved

You can investigate it:

git show 638ec51

Git will show the commit information and the changes introduced by that commit.

This is useful when someone asks:

"What exactly did this commit change?"

Instead of guessing, inspect the commit.

8. git log -p — Investigate a File's History

Suppose you have a file:

kernel_tuning.txt

You can see its history:

git log --oneline -- kernel_tuning.txt

You might see:

5f36a9b add kernel tuning notes

To see the actual changes:

git log -p -- kernel_tuning.txt

This can show you when the file was created and what was changed over time.

This is particularly useful for:

• Nginx configuration

• Docker files

• Kubernetes YAML

• Terraform

• Ansible

• system configuration

• application configuration

9. git blame — Who Changed This Line?

Sometimes you find a suspicious line in a configuration file.

For example:

server_port=9090

You want to know:

"Who introduced this?"

Run:

git blame config.txt

Git can show information such as:

5f36a9b5 (eather009 2026-08-31) server_port=9090

Now you know:

• the commit

• the author

• the date

• the line associated with that commit

You can then investigate further:

git show 5f36a9b5

A useful investigation workflow is:

git blame
    ↓
Find commit
    ↓
git show
    ↓
Understand change

10. git blame Doesn't Mean "Find Someone to Blame"

The name can be misleading.

In professional environments, git blame should not be used to point fingers.

Its purpose is to answer:

"What is the history of this line?"

For example, as a System Engineer troubleshooting a production issue, you may want to know who introduced a configuration change so you can find the related ticket, pull request, or technical discussion.

It's a history investigation tool.

11. What Happens If You Make a Mistake?

Now let's talk about one of Git's most powerful—and potentially dangerous—commands:

git reset

Imagine your history is:

A → B → C

and you're currently at C.

You decide that you want to move your branch back one commit.

You might run:

git reset --hard HEAD~1

Now:

A → B

Your branch has moved backward.

But what happened to C?

This is where many beginners panic.

12. Be Careful With git reset --hard

The --hard option is powerful because it changes more than just the branch pointer.

It can also discard changes in your working directory.

For example, if you have uncommitted work:

config.yml

and run:

git reset --hard

those uncommitted changes can be lost.

So before using --hard, ask yourself:

What am I resetting?
What changes will disappear?
Do I have a backup?
Has this commit already been pushed?

If you're not sure, stop and investigate first.

13. The Three Common Reset Modes

You will commonly hear about:

git reset --soft
git reset --mixed
git reset --hard

They differ in what happens to your changes.

--soft

Moves the branch pointer but keeps changes staged.

Commit
  ↓
Branch moves backward
  ↓
Changes remain staged

Useful when you want to redo or combine commits.

--mixed

This is the default reset mode.

git reset HEAD~1

The branch moves backward and changes remain in your working directory, but they are no longer staged.

--hard

git reset --hard HEAD~1

Moves the branch backward and resets the working directory to match it.

This can discard uncommitted changes.

Use it carefully.

14. What Is HEAD?

You'll see HEAD everywhere in Git.

For example:

git reset --hard HEAD~1

Think of HEAD as:

Where I am currently checked out.

If your history is:

A → B → C
        ↑
       HEAD

then:

HEAD

points to C.

And:

HEAD~1

means:

The commit before HEAD.

So:

HEAD
 ↓
C

HEAD~1
 ↓
B

And:

HEAD~2

would point to:

A

15. The Git Safety Net: git reflog

Now we reach one of the most useful commands for Git recovery:

git reflog

Imagine you accidentally do:

git reset --hard HEAD~1

and your commit seems to disappear.

You run:

git log --oneline

and don't see the commit anymore.

Don't panic.

Try:

git reflog

You may see something like:

638ec51 HEAD@{0}: reset: moving to HEAD~1
eed4497 HEAD@{1}: commit: updated messy1.txt
638ec51 HEAD@{2}: commit: conflict resolved

Notice:

eed4497

Your previous commit is still referenced in the reflog.

16. Recovering a Commit With reflog

If you determine that:

eed4497

is the commit you want to recover, you can move your branch back to it:

git reset --hard eed4497

Your history is restored.

This is why learning reflog is so valuable.

A mistake like:

"I accidentally reset my branch!"

doesn't necessarily mean:

"My work is gone forever!"

Git often still knows where your repository's HEAD has been.

17. git log vs git reflog

These commands serve different purposes.

git log

Shows the commit history reachable from your current references.

git log --oneline

Think:

"Show me the project's history."

git reflog

Shows movements of references such as HEAD.

git reflog

Think:

"Show me where my repository was recently."

This makes reflog especially useful for recovery.

18. A Real Troubleshooting Scenario

Imagine you're a DevOps engineer.

A server configuration was changed and the application started behaving unexpectedly.

You want to investigate.

Step 1 — Check the repository

git status

Step 2 — Check recent history

git log --oneline --decorate --graph

Step 3 — Check the configuration's history

git log --oneline -- nginx.conf

Step 4 — See exactly what changed

git log -p -- nginx.conf

Step 5 — Find who changed the suspicious line

git blame nginx.conf

Step 6 — Inspect the commit

git show <commit-id>

Now you have a structured investigation:

What happened?
      ↓
git log

What changed?
      ↓
git log -p / git show

Who changed it?
      ↓
git blame

When did it happen?
      ↓
git log

What if history was accidentally changed?
      ↓
git reflog

This is where Git becomes extremely useful beyond simple source-code management.

19. Git Recovery Mindset

When something goes wrong, avoid immediately trying commands you found from a random Stack Overflow answer.

Instead:

STOP
 ↓
git status
 ↓
Understand current state
 ↓
git log
 ↓
Understand history
 ↓
git reflog if necessary
 ↓
Choose recovery method

This habit can save you from making the situation worse.

20. Common Git Mistakes

Mistake 1: Committing directly to main

For team development, use a feature or bugfix branch when your team's workflow requires it.

Mistake 2: Using meaningless commit messages

Avoid:

fix
update
test
changes

Prefer:

fix database connection timeout
add system monitoring configuration
update deployment documentation

Mistake 3: Running git reset --hard without understanding it

This is one of the easiest ways to lose uncommitted work.

Mistake 4: Panicking during a merge conflict

A conflict is not a disaster.

Git is simply asking you to make a decision.

Mistake 5: Forgetting to check the repository state

When confused:

git status

Seriously.

This one command solves a surprising number of Git mysteries.

21. Git Commands You Should Now Know

After completing this three-part series, you should be comfortable with these commands:

Basic

git status
git add
git commit
git log
git diff
git show

Remote

git remote -v
git fetch
git pull
git push

Branching

git branch
git branch -a
git switch
git switch -c

Temporary work

git stash
git stash list
git stash pop

Collaboration

git merge
git merge --squash

Investigation & recovery

git log -p
git blame
git reset
git reflog

You don't need to memorize all of them.

What matters is knowing when and why you would use them.

22. A Practical Git Workflow

Putting everything together, a typical feature workflow could look like this:

git switch master
git pull

git switch -c feature/my-task

# Make changes

git status
git diff

git add .
git commit -m "add my feature"

git push -u origin feature/my-task

After the feature is reviewed:

git switch master
git pull

git merge --squash feature/my-task
git commit -m "add my feature"

git push

If something goes wrong:

git status
git log --oneline --decorate --graph
git reflog

And if there's a conflict:

git status

# Fix the conflicted files

git add <file>
git commit -m "resolve merge conflict"

23. The Most Important Git Lesson

Git isn't really about memorizing commands.

It's about understanding state and history.

When you know:

Where am I?
     ↓
git status

What happened?
     ↓
git log

What changed?
     ↓
git diff / git show

Who changed it?
     ↓
git blame

How did branches evolve?
     ↓
git log --graph

Where was HEAD previously?
     ↓
git reflog

you can solve most everyday Git problems logically.

Final Thoughts

If you started this series knowing almost nothing about Git, you now have the foundation to work with Git repositories from the command line.

The journey was:

PART 1
Git Fundamentals
     ↓
status → add → commit → push

Then:

PART 2
Collaboration
     ↓
branch → switch → stash → merge

And finally:

PART 3
Troubleshooting
     ↓
conflict → log → show → blame → reset → reflog

The command line may look intimidating at first, especially if you're coming from a GUI.

But once you understand what's happening underneath the buttons, Git becomes much easier to reason about.

And remember one of the most useful rules in Git:

When something goes wrong, don't panic. Check the state, inspect the history, and then decide.

git status
git log --oneline --decorate --graph
git reflog

Those three commands alone can take you surprisingly far.

What's Next?

Git is only one part of modern DevOps.

Once you're comfortable with Git, the next step is understanding how Git connects to the larger engineering workflow:

Git
 ↓
GitHub
 ↓
Pull Request
 ↓
Code Review
 ↓
CI
 ↓
Automated Testing
 ↓
Build
 ↓
Deployment
 ↓
Monitoring

That is where Git moves from being a version control tool to becoming part of a complete DevOps delivery pipeline.