GIT & GITHUB Complete Notes for DevOps Foundations

GIT & GITHUB

Complete Notes for DevOps Foundations

Covers Syllabus Unit 1.1 (DevOps Principles) and 1.2 (Git Fundamentals)

Scope of this document:

DevOps basics & Infrastructure as Code  •  Version control concepts

Git commands (init, add, commit, branch, merge, push, pull, clone)

GitHub collaboration workflow

(Jenkins / Jira topics are outside the scope of this note set)

Table of Contents

1.  Foundations of DevOps  .................................................  3

2.  Version Control Systems — Centralized vs Distributed  ......  4

3.  Git Fundamentals  ..........................................................  5

     3.1  What is Git?

     3.2  The Git Workflow — Four Areas

     3.3  Core Git Commands

     3.4  Step-by-Step: Repository, Commit, Push

     3.5  Branching and Merging

     3.6  Cloning and Pulling

4.  GitHub Collaboration Basics  ..........................................  8

5.  Quick Revision — All Commands  ......................................  9

Git_GitHub_Complete_Notes.docx

Download DOCX • 341KB

1. Foundations of DevOps

1.1 What is DevOps?

DevOps is a set of practices, culture, and tooling that combines Software Development (Dev) and IT Operations (Ops) into a single, continuous workflow. Its goal is to shorten the software development lifecycle and deliver high-quality software frequently and reliably, by breaking down the traditional wall between developers (who write code) and operations teams (who deploy and maintain it).

Key characteristics of DevOps:

•     Collaboration — Dev and Ops work as one team, sharing responsibility for the full lifecycle.

•     Automation — repetitive tasks (build, test, deploy, provisioning) are automated wherever possible.

•     Continuous Integration / Continuous Delivery (CI/CD) — code is integrated, tested, and released in small, frequent increments.

•     Monitoring & Feedback — systems are continuously monitored and feedback is fed back into development.

•     Infrastructure as Code (IaC) — infrastructure is provisioned and managed using code and version control, not manual steps.

CI/CD Concepts (brief)

•     Continuous Integration (CI): developers merge code changes into a shared repository frequently (several times a day); each merge triggers an automated build and test.

•     Continuous Delivery (CD): every change that passes CI is automatically prepared for a release to production (release itself may be manual).

•     Continuous Deployment: an extension of Continuous Delivery where every change that passes all tests is automatically deployed to production, with no manual step.

1.2 Infrastructure as Code (IaC)

Infrastructure as Code is the practice of managing and provisioning computing infrastructure (servers, networks, load balancers, databases, etc.) through machine-readable definition files, rather than manual configuration or interactive tools. IaC scripts/configuration are stored in a version control system such as Git, just like application source code.

Two key benefits of IaC:

•     Consistency & Repeatability — the same configuration file always produces an identical environment, eliminating configuration drift and the classic "it works on my machine" problem.

•     Speed & Automation — environments can be created, changed, or destroyed automatically in minutes through a pipeline, instead of manually provisioning servers over hours or days.

Other commonly cited benefits (for completeness):

•     Version control — infrastructure changes can be tracked, reviewed, and rolled back like application code.

•     Cost efficiency — resources can be spun up only when needed and torn down automatically, avoiding waste.

•     Disaster recovery — an entire environment can be rebuilt quickly from code if it is lost.

Sample answer — Q1: Define DevOps and list two benefits of Infrastructure as Code (IaC).

DevOps is a culture and set of practices that unifies software development and IT operations to enable faster, more reliable, and more frequent software releases through collaboration and automation. Two benefits of IaC: (1) it produces consistent, repeatable environments because the same code always builds the same infrastructure, removing manual configuration errors; and (2) it speeds up provisioning, letting teams create or tear down environments automatically in minutes as part of an automated pipeline.

1.3 Automation Overview

Automation in DevOps refers to replacing manual, repetitive human tasks with scripts and tools across the entire software delivery pipeline — building code, running tests, provisioning servers, and deploying releases. Version control (Git) sits at the foundation of this automation: every automated pipeline is normally triggered by a change pushed to a Git repository.

2. Version Control Systems — Centralized vs Distributed

A Version Control System (VCS) records changes to files over time so that specific versions can be recalled later. There are two broad models: Centralized VCS and Distributed VCS.

2.1 Centralized Version Control Systems (CVCS)

Examples: SVN (Subversion), CVS, Perforce.

•     A single central server holds the complete history of the project.

•     Developers check out a working copy of the latest snapshot from that server, but do not have the full history locally.

•     Every meaningful operation (commit, view history, compare versions) requires network access to the central server.

•     If the central server goes down, no one can collaborate at all, and if the server's disk is lost without a backup, the entire project history is lost.

2.2 Distributed Version Control Systems (DVCS)

Examples: Git, Mercurial.

•     Every developer clones a full copy of the repository, including its entire history, onto their own machine.

•     Most operations (commit, view log, diff, branch, merge) are performed locally and instantly — no network needed.

•     There can still be one agreed "central" remote (e.g. a repository hosted on GitHub) that the team treats as the source of truth, but technically any clone can act as a remote for any other clone.

•     Because every clone is a full backup, losing the server does not lose the project history.

Fig. 2.1 — Centralized VCS (single server, thin clients) vs Distributed VCS (every node has full history).

2.3 Comparison Table

Aspect	Centralized VCS (e.g. SVN)	Distributed VCS (e.g. Git)
Repository copy	Only the server has full history	Every clone has full history
Working offline	Very limited (no commit/log/diff)	Full support (commit, branch, log, diff offline)
Speed	Slower — most actions hit the network	Faster — most actions are local
Single point of failure	Yes — server loss can be catastrophic	No — any clone can restore the project
Branching	Heavyweight, often server-side	Lightweight, cheap, encouraged constantly
Typical remote workflow	Checkout / Commit directly to server	Clone, commit locally, then Push/Pull to sync

Sample answer — Q8: Explain the difference between centralized and distributed version control systems, using Git as an example.

In a centralized VCS such as SVN, only one central server stores the full project history; developers check out a working copy and must contact the server for almost every operation, so the server is a single point of failure. In a distributed VCS such as Git, every developer clones a complete copy of the repository — including the full commit history — onto their own machine. This means commits, branching, merging, and viewing history all happen locally without needing network access, and the project can be fully recovered from any single clone if the central remote (e.g. GitHub) is lost. A remote like GitHub is still used as an agreed central point for collaboration via push/pull, but it is a convention, not a technical requirement, unlike in a centralized system.

3. Git Fundamentals

3.1 What is Git?

Git is a free, open-source distributed version control system created by Linus Torvalds in 2005. It tracks changes to files, allows multiple people to work on the same project without overwriting each other's work, and keeps a complete, browsable history of the project.

3.2 The Git Workflow — Four Areas

•     Working Directory — the actual files on disk that you edit.

•     Staging Area (Index) — a holding area where you list the exact changes you want to include in the next commit.

•     Local Repository — the .git database on your machine where committed snapshots are permanently stored.

•     Remote Repository — a copy of the repository hosted elsewhere (e.g. on GitHub) used to share work with others.

Fig. 3.1 — How changes move between the four Git areas, and the command used at each step.

3.3 Core Git Commands

Command	Purpose
git init	Turns the current folder into a new, empty Git repository (creates a .git folder).
git clone <url>	Copies (downloads) an existing remote repository, including its full history, to your machine.
git status	Shows which files are modified, staged, or untracked.
git add <file> / git add .	Moves changes from the working directory into the staging area.
git commit -m "msg"	Saves the staged changes as a new permanent snapshot in the local repository.
git log	Shows the commit history.
git branch <name>	Creates a new branch.
git checkout <branch> / git switch <branch>	Switches the working directory to a different branch.
git checkout -b <name>	Creates a new branch and switches to it in one step.
git merge <branch>	Merges the specified branch into the current branch.
git remote add origin <url>	Links a local repository to a remote repository, naming it "origin".
git push origin <branch>	Uploads local commits on a branch to the remote repository.
git fetch	Downloads new commits from the remote without merging them into your working files.
git pull	Equivalent to git fetch followed by git merge — downloads and immediately merges remote changes.

3.4 Step-by-Step: Creating a Repository, Committing, and Pushing

This is the standard sequence to create a new local repository, save a file's changes, and publish it to a remote such as GitHub.

1.   Create a project folder and turn it into a Git repository:

mkdir my-project

cd my-project

git init

2.   Configure your identity (first time only, per machine):

git config --global user.name "Your Name"

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

3.   Create or edit a file, then check its status:

echo "Hello Git" > file1.txt

git status

4.   Stage the file (add it to the staging area):

git add file1.txt

# or, to stage everything changed:

git add .

5.   Commit the staged changes to the local repository:

git commit -m "Add file1.txt with initial content"

6.   Link the local repository to a remote (e.g. an empty GitHub repo you created):

git remote add origin https://github.com/<username>/<repo>.git

7.   Push the commit to the remote repository:

git push -u origin main

# -u sets 'origin main' as the default upstream for future pushes

Sample answer — Q4 / Q13: Demonstrate the Git commands required to create a repository, add a file, commit it, and push it to a remote / clone a remote repository and pull the latest changes.

To create a repository, add a file, commit it, and push it: run git init to start a repository, edit or create a file, run git add <file> to stage it, run git commit -m "message" to save it locally, then git remote add origin <url> to link a remote and git push -u origin main to upload the commit. To instead get an existing project, use git clone <url>, which downloads the full repository including its history into a new folder; afterwards, run git pull inside that folder at any time to fetch and merge the latest changes from the remote into your local copy and working files.

3.5 Branching and Merging

A branch is an independent line of development. The default branch is usually called main (or master). Branches let a developer work on a new feature or fix in isolation, without affecting the stable code, and later combine (merge) that work back in.

•     git branch feature/login — create a new branch called feature/login from the current commit.

•     git checkout feature/login (or git switch feature/login) — move to that branch; further commits are added only to it.

•     git checkout -b feature/login — shortcut that creates and switches in one command.

•     git checkout main then git merge feature/login — switch back to main and merge the feature branch's commits into it.

•     A merge commit is created automatically when the two branches' histories are joined and there is no way to simply move the pointer forward (a "fast-forward").

Fig. 3.2 — A feature branch created from main, developed with its own commits, and merged back.

3.6 Cloning and Pulling — Working with an Existing Remote Repository

Use this workflow when the repository already exists on GitHub and you need a local working copy that you keep up to date.

8.   Clone the remote repository to create a local copy:

git clone https://github.com/<username>/<repo>.git

cd <repo>

9.   Later, to bring in the newest changes made by others:

git pull origin main

# fetches new commits from 'origin' and merges them into your current branch

10.If you only want to see what changed without merging yet:

git fetch origin

git log origin/main   # inspect incoming commits

git merge origin/main # merge them in when ready

Sample answer — Q13: Illustrate, using Git commands, how to clone a remote repository and pull the latest changes into a local copy.

First, run git clone https://github.com/<username>/<repo>.git to download the full repository — including all history — into a new local folder, then cd into that folder. From then on, whenever the remote repository changes, running git pull origin main inside the local folder fetches the new commits from the remote and automatically merges them into the current branch, updating the working files.

4. GitHub Collaboration Basics

4.1 What is GitHub?

GitHub is a cloud-hosting platform for Git repositories. Git itself is the version control tool that runs on your machine; GitHub is a website/service that hosts Git repositories online and adds collaboration features on top of Git — such as Pull Requests, Issues, code review, and access control — so that distributed teams can work together on the same codebase.

4.2 Typical GitHub Collaboration Workflow

11.Fork or clone the repository — Fork creates your own copy of someone else's repository under your account; clone (for repos you already have access to) copies it locally.

12.Create a feature branch for your change: git checkout -b feature/my-change

13.Make changes, then git add, git commit.

14.Push the branch to GitHub: git push origin feature/my-change

15.Open a Pull Request (PR) on GitHub, comparing your branch against main, so teammates can review the change.

16.After review and approval, the PR is merged into main on GitHub (this is equivalent to a git merge on the server).

17.Everyone else runs git pull to bring the newly merged change into their own local main branch.

4.3 Git Collaboration Basics — Key Terms

Term	Meaning
Repository (repo)	A project's folder tracked by Git, containing all files and their full history.
Remote	A version of the repository hosted elsewhere (commonly named "origin").
Fork	Your own personal copy of someone else's repository on GitHub.
Pull Request (PR)	A request on GitHub to merge changes from one branch/fork into another, with room for review and discussion.
Merge conflict	Occurs when Git cannot automatically combine changes because the same lines were edited differently on both sides; it must be resolved manually.
.gitignore	A file listing file/folder patterns that Git should not track (e.g. build output, secrets).

4.4 Resolving a Merge Conflict (Overview)

A merge conflict happens when Git cannot decide which version of a change to keep. Git marks the conflicting section directly inside the file:

<<<<<<< HEAD

your current branch's version of the line(s)

=======

the incoming branch's version of the line(s)

>>>>>>> feature/login

To resolve it: open the file, edit it to keep the correct content, remove the <<<<<<<, =======, >>>>>>> markers, then:

git add <file>

git commit -m "Resolve merge conflict"

5. Quick Revision — All Git/GitHub Commands in One Place

Stage	Command
Setup	git init | git clone <url> | git config --global user.name/user.email
Check state	git status | git log | git diff
Save work	git add <file> | git add . | git commit -m "message"
Branching	git branch <name> | git checkout -b <name> | git checkout <name> | git merge <name>
Sync with remote	git remote add origin <url> | git push origin <branch> | git fetch | git pull
Undo / inspect	git diff | git log --oneline | git checkout -- <file> (discard local change)

5.1 Exam-style Question Map (Git/GitHub only)

From the question list provided, these are answered directly in this note set:

•     Q1 (part) — Define DevOps and benefits of IaC → Section 1.

•     Q4 — Git commands to create a repo, add, commit, push → Section 3.4.

•     Q8 — Centralized vs Distributed VCS, using Git → Section 2.

•     Q9 (part) — Role of IaC in DevOps automation → Section 1.2/1.3.

•     Q13 — Clone a remote repository and pull latest changes → Section 3.6.

Questions about Jenkins (freestyle projects, declarative/scripted pipelines, plugins, CI pipeline design) and about Jira are outside the Git/GitHub scope of this document, as requested.