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

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?

---

Frequently Asked Questions

What is Git and why is it used?

Git is a distributed version control system that records snapshots of a project over time, so you can see what changed, when, by whom and why, and return to any earlier state. It is used because it makes two otherwise hard things routine: several people editing the same codebase without overwriting each other, and experimenting on a branch without risking the working version. Every modern deployment pipeline is triggered by Git, which is why it is the one tool essentially every developer and operator shares.

What is the difference between Git and GitHub?

Git is the version control software that runs on your machine and does all the actual work. Committing, branching, merging, storing history. GitHub is a commercial website that hosts Git repositories and adds collaboration features Git does not have: pull requests, issues, code review, permissions and CI. Git works completely without GitHub, and GitLab, Bitbucket and self-hosted alternatives provide the same role. Confusing the two is common because most people meet Git through GitHub.

What does "distributed" mean in distributed version control?

Every clone is a complete repository, with the full history and every branch, rather than a thin checkout of a central server. That has three practical consequences: nearly every operation, log, diff, branch, commit, is local and therefore instant, you can work entirely offline and sync later, and there is no single point of failure because every clone is effectively a backup. Centralised systems such as SVN keep history only on the server, which is why they needed a connection for operations Git does in milliseconds.

Does Git store a copy of every file in every commit?

Conceptually yes. Each commit references a complete snapshot of the tree. Physically no: Git stores each unique piece of content once, addressed by its SHA-1 hash, so a file unchanged across a thousand commits is stored once and referenced a thousand times. It later repacks objects into compressed packfiles that store deltas between similar ones. This is why a repository with years of history is often smaller than the working directory it produced.

Do I need to know Git to work in DevOps?

Yes, and not merely to store code. Infrastructure as code, pipeline definitions, Kubernetes manifests and configuration all live in Git, and GitOps goes further by making the repository the declared desired state of production. That means a Git revert can be a rollback, a branch protection rule can be a deployment control, and a commit message can be the audit record for a change. Git fluency is closer to a prerequisite than a skill in this field.

What are the main Git terms a beginner needs?

Six carry most of the weight. A repository is the project plus its complete history. A commit is one recorded snapshot with a message and a parent. A branch is a movable pointer to a commit, which is why creating one is instant. HEAD is where you currently are. A remote is another copy of the repository, conventionally named origin. The staging area is the draft of your next commit, and it is the concept that makes the add-then-commit two-step make sense.