Git

In this lesson we cover Git — the distributed version control system used to track source code, configuration files, playbooks, and more. Whether you’re a developer, system administrator, support engineer, or project manager, basic Git skills are essential for downloading code, managing changes, and collaborating with others. What we’ll cover

What Git does and why it matters.
How to install Git and verify the installation.
Creating and working with repositories (local and remote).
How to stage, commit, and inspect changes.
Common workflows and next steps (clone, push, pull) and the difference between Git and hosting services like GitHub.

This article focuses on the essentials so you can quickly download code, make local changes, and share them to a remote repository. Git can be deep — consider this a practical starting point. What problem does Git solve? Imagine a small Flask app with a handful of files (LICENSE, README.md, requirements.txt, main.py). With only occasional edits you might remember your changes. As the project grows or multiple people contribute, you need a way to:

Track what changed, when, and who changed it.
Let multiple developers work simultaneously without overwriting each other.
Create named snapshots (versions) of the project at important milestones.

Git addresses these needs by tracking changes to files and providing tools to create commits, branch, merge, and synchronize with remote repositories. High-level Git workflow

Initialize a Git repository in your project directory (git init) or clone an existing remote repository (git clone).
Choose which files Git should track (use .gitignore to exclude files).
Stage a coherent set of changes into the index using git add.
Create a commit (git commit) to record a snapshot.
Repeat: edit → stage → commit; push and pull to synchronize with remote repositories when collaborating.

A few important points

Git does not auto-version on save. You explicitly create versions with git add + git commit.
Stage only the changes you intend to include in a commit to keep history focused.
The working directory, staging area (index), and the commit history are the main Git states to understand.

Concise textual summary

Working directory: your files.
.git directory: repository metadata created by git init.
Staging area (index): git add selects what goes into the next commit.
Commit: git commit records the staged snapshot as a new version.

A diagram explaining the Git workflow, showing a repository file tree (LICENSE, README.md, main.py, utils.py, etc.) and columns for Version 1/2/3 plus a Staging area highlighting staged files. On the right are numbered steps like initialize a Git repository, configure files to track, stage changes, and commit changes.

Getting started: commands and examples

Install Git

On CentOS/RHEL:

sudo yum install -y git

For other operating systems, follow the official instructions: https://git-scm.com/downloads

Verify the installation:

git --version
# Example output:
# git version 2.31.1

Initialize a repository To start tracking an existing project directory:

git init
# Example output:
# Initialized empty Git repository in my-application/.git/

This creates a hidden .git directory that contains all repository metadata and history.

Check repository status Before adding files, check what Git sees:

git status
# Example output:
# On branch master
# No commits yet
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#  LICENSE
#  README.md
#  backend.py
#  cache.py
#  db.py
#  main.py
#  requirements.txt
#  utils.py
#  notes.txt

Decide which files to track You can add each file explicitly:

git add LICENSE README.md backend.py cache.py db.py main.py requirements.txt utils.py

Or add everything and use a .gitignore to exclude personal or generated files such as notes.txt. .gitignore is the standard way to exclude files from being tracked. After staging, verify:

git status
# Example output indicating staged files:
# On branch master
# No commits yet
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#  new file:   LICENSE
#  new file:   README.md
#  new file:   backend.py
#  new file:   cache.py
#  new file:   db.py
#  new file:   main.py
#  new file:   requirements.txt
#  new file:   utils.py
#
# Untracked files:
#  notes.txt

Modify files and stage specific changes When you edit a tracked file (e.g., main.py) Git marks it as modified:

git status
# Example output:
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git restore <file>..." to discard changes in working directory)
#
#   modified:   main.py

Stage the modified file:

git add main.py

You can also stage only parts of a file (git add -p) when you want finer-grained commits.

Commit changes Create a commit from staged changes and include a descriptive message:

git commit -m "Initial commit"
# Example output:
# [master (root-commit) f5cdb03] Initial commit
#  8 files changed, 1 insertion(+)
#  create mode 100644 LICENSE
#  create mode 100644 README.md
#  create mode 100644 backend.py
#  create mode 100644 cache.py
#  create mode 100644 db.py
#  create mode 100644 main.py
#  create mode 100644 requirements.txt
#  create mode 100644 utils.py

Write commit messages that clearly describe what changed and why. Small, focused commits with meaningful messages make history easier to read, review, and revert if needed.

How git add behaves

Untracked files: git add <file> both starts tracking and stages the file.
Tracked and modified files: git add <file> stages the current changes for the next commit.
Partial staging: use git add -p to interactively choose hunks to stage.

Quick reference table

Command	Purpose	Example / Notes
`git init`	Initialize a local repository	Creates `.git` directory
`git status`	Show repository state	See untracked, staged, and modified files
`git add <file>`	Stage file(s) for commit	Stages changes to be included in next commit
`git commit -m "msg"`	Create a commit from staged files	Records snapshot with message
`git clone <repo>`	Copy a remote repo locally	Use when starting from a remote source
`git push`	Send commits to a remote	Requires a configured remote (e.g., origin)
`git pull`	Fetch & merge from remote	Sync local branch with remote branch

Summary and next steps

Core local workflow: git init → git add → git commit.
Use git status often to understand repository state.
Practice creating commits, making targeted changes, and using .gitignore to exclude local files.
Next topics to learn: cloning remote repositories (git clone), connecting to remotes (git remote add), pushing and pulling (git push, git pull), branching and merging, and collaboration workflows (forks, pull requests).

Useful references

Official Git downloads and documentation: https://git-scm.com/
Learn Git basics with interactive tutorials: https://try.github.io/ or https://learngitbranching.js.org/

That’s the end of this introduction. Practice these steps hands-on to become comfortable; remote collaboration (clone, push, pull, branching) is the natural next step.

Introduction

Linux Basics

Networking Basics

Applications Basics

Source Control Management (SCM)

Web Server

Database Basics

Security

General Prerequisites

2 Tier Applications

Lab Setup

Conclusion

Watch Video

Practice Lab