Introduction to Git

What Is Git?

Git is a version control system that tracks changes to files over time. It is most often used for source code, but it can track almost any text-based project. Instead of saving files as final-v2-really-final.txt, Git stores a history of changes so you can see what changed, who changed it, and when it changed.

In practice, Git lets you work safely. You can experiment, undo mistakes, compare versions, and collaborate with other people without constantly copying folders by hand.

Tip: Think of Git as a timeline for your project. Every important save point becomes part of a history you can inspect and reuse later.

Why Version Control Matters

Without version control, teams run into familiar problems:

• A bug appears and nobody knows which change caused it
• Two people edit the same file and overwrite each other
• A working version gets replaced by a broken one
• It is hard to review changes before they go live
• Rolling back to a known good state takes too long

Git solves these problems by recording snapshots called commits. Each commit has an ID, message, author, and timestamp. Because Git stores history, you can answer useful questions like:

• What changed in this file last week?
• Which commit introduced this line?
• Can we restore the version from yesterday?
• Can we review this feature before merging it?

A Real Example

Imagine you change a deployment script and production starts failing. With Git, you can compare the current script to the previous commit and quickly spot the mistake:

git log --oneline
git diff HEAD~1 HEAD -- deploy.sh

That is far safer than guessing or restoring random backup files.

How Git Stores History

Git does not track “the latest file only.” It stores snapshots of your project over time. When you create a commit, Git records the state of tracked files at that moment.

A simple workflow looks like this:

git init
git add app.js
git commit -m "Add initial app file"

Later, after editing the file again:

git add app.js
git commit -m "Update startup message"

Now you have two checkpoints. You can inspect either version whenever needed.

Git vs Other Version Control Systems

Git is not the only version control system. Older tools include Subversion (SVN), Mercurial, and CVS.

Here is a practical comparison:

Git became popular because it is fast, reliable, and excellent at branching and merging. Modern platforms such as GitHub, GitLab, and Bitbucket also made Git collaboration easier.

Why Teams Prefer Git

Teams often choose Git because it supports:

• Local commits without internet access
• Cheap, lightweight branching
• Strong tooling around code review and pull requests
• Easy cloning of full project history
• Flexible workflows for individuals and teams

Centralized vs Distributed Version Control

The biggest conceptual difference is between centralized and distributed systems.

Centralized Version Control

In a centralized system, there is one main server with the official history. Developers check files in and out from that server.

Benefits:

• Simple to understand at first
• One obvious central source of truth

Drawbacks:

• Limited offline work
• Central server is a single point of failure
• Branching and merging may feel heavier

Distributed Version Control

Git is a distributed version control system. Every clone contains the full repository history, not just the latest files.

Benefits:

• You can commit locally without network access
• Cloning acts as a backup of history
• Branching and merging are fast
• Developers can experiment safely in local branches

Note: Even though Git is distributed, teams usually still use a shared remote repository such as GitHub as the collaboration hub.

Git in Everyday DevOps Work

Git is not only for application code. DevOps teams use it for:

• Infrastructure as Code files
• CI/CD pipeline definitions
• Kubernetes manifests
• Terraform modules
• Shell scripts and automation
• Documentation and runbooks

This matters because change history is critical in operations. If a deployment pipeline breaks, Git helps you trace the exact configuration change that caused it.

Key Terms to Remember

Repository

A repository or repo is the project folder Git tracks, including its history.

Commit

A commit is a saved snapshot of tracked changes.

Branch

A branch is an independent line of work, often used for features or fixes.

Clone

A clone is a full local copy of a repository.

Remote

A remote is a shared repository location, such as one hosted on GitHub.

What You Should Remember

Git helps you manage change safely. It gives you history, accountability, collaboration, and the confidence to experiment without losing work. Compared with older centralized tools, Git gives every developer a full local history and makes branching much easier.

If you remember one idea, remember this: Git is not just a backup tool. It is a system for working with change in a controlled, reviewable way.

Test Your Understanding

Let's see how well you understood the concepts! These exercises will help reinforce what you just learned.

Exercise 1: Distributed history

Scenario: You clone a Git repository before boarding a flight and lose internet access.

Question: Which capability from this lesson still lets you inspect old commits and make new local commits while offline?

Exercise 2: Snapshots vs file copies

Scenario: A teammate keeps saving files as deploy-final-v3-really-final.sh to track changes manually.

Question: What Git concept from this tutorial directly solves that problem?

Exercise 3: Git in DevOps work

Scenario: A deployment pipeline started failing after a recent configuration edit.

Question: According to the tutorial, why is Git especially useful in this DevOps situation?