Unit 2: Version Control & Source Code Management

Version control is the discipline of recording changes to files over time so that specific versions can be recalled, compared, and shared. In DevOps it is the single source of truth from which builds, tests, and deployments are triggered, making it the foundation of continuous integration.

• Definition: A Version Control System (VCS) is software that tracks every modification to a set of files as a sequence of revisions, each identified uniquely and attributable to an author.
• Distributed model: Git (created by Linus Torvalds, 2005) is a distributed VCS — every clone holds the full history, unlike centralised systems (SVN, CVS) that keep history only on a server.
• Content addressing: Git stores snapshots, not diffs; each object is keyed by a 40-character SHA-1 hash of its contents (e.g. a1b2c3...), guaranteeing integrity.
• Three states: A file is modified (changed but not staged), staged (marked for the next commit), or committed (safely stored in the local database).

II. Why Version Control?

The motivating problem and the guarantees Git provides.

A. Purpose and Principle

Version control exists to make change safe, collaborative, and reversible.

• History and traceability: Every change carries author, timestamp, and message, so git log answers who changed what, when, and why.
• Concurrency: Multiple developers work in parallel without overwriting one another; Git merges their work automatically where lines do not overlap.
• Recovery: Any past state can be restored — git checkout <hash> reconstructs the project exactly as it was at that commit.
• Auditing and rollback: In DevOps a bad deploy is reversed by reverting a commit, not by manual file surgery, keeping the pipeline deterministic.

III. Git Repositories

The container that holds a project's complete history.

A. Definition and Structure

A repository is the .git directory plus the working tree it manages.

• The .git directory: Holds all objects (blobs, trees, commits, tags), refs (refs/heads, refs/tags), the HEAD pointer, and configuration.
• Working tree: The checked-out files you edit; the index (staging area) sits between it and the repository.
• Local vs remote: A local repository lives on your machine; a remote (e.g. on GitHub) is a shared copy others push to and pull from, referenced by a name such as origin.
• Bare repository: A repository with no working tree (git init --bare), used on servers purely to receive pushes.

IV. Git Cmd/Bash: Basic Operations

Initialising, staging, and synchronising a repository.

A. init

Creates a new, empty repository in the current directory.

• Command: git init writes the .git directory; nothing is tracked until files are added.
• Cloning alternative: git clone <url> initialises and copies an existing remote, setting origin automatically.

B. add

Moves changes from the working tree into the staging area.

• Command: git add <file> stages one file; git add . stages all changes in the current path.
• Effect: The file's current snapshot is written to the index, becoming part of the next commit only.

C. push

Uploads local commits to a remote branch.

git push -u origin main   # -u sets the upstream tracking branch

• Behaviour: Transfers objects the remote lacks and updates the remote branch pointer; rejected if the remote has commits you have not merged.

D. pull

Downloads and integrates remote changes.

• Composition: git pull = git fetch (download objects) + git merge (integrate into current branch).
• Rebase variant: git pull --rebase replays your commits on top of fetched work, avoiding a merge commit.

V. Core History Operations

Building and reshaping the commit graph.

A. Commits

A commit is an immutable snapshot of the staged files plus metadata.

• Command: git commit -m "message" records the index; -a auto-stages tracked files.
• Contents: Tree hash, parent commit hash(es), author, committer, and message.
• Identity: The commit's own SHA-1 makes it addressable; HEAD normally points to the latest commit on the current branch.

B. Branching

A branch is a lightweight, movable pointer to a commit.

• Create/switch: git branch feature then git switch feature, or git checkout -b feature in one step.
• Cost: Creating a branch writes a single 41-byte file, so branching is effectively free.
• Purpose: Isolates work-in-progress from the stable line (main) until it is ready to integrate.

C. Merging

Combines the histories of two branches.

1. Fast-forward: When the target has no new commits, Git simply moves the pointer forward — no merge commit is created.
2. Three-way merge: When both branches diverged, Git uses the common ancestor plus both tips to build a new merge commit with two parents.

git switch main
git merge feature

D. Tagging

Marks a specific commit as significant, typically a release.

• Lightweight tag: git tag v1.0 — a bare pointer to a commit.
• Annotated tag: git tag -a v1.0 -m "Release 1.0" — a full object storing tagger, date, and message; preferred for releases.
• Push: Tags are not pushed by default; use git push origin v1.0 or --tags.

E. Rebasing

Rewrites history by replaying commits onto a new base.

• Command: git rebase main takes the current branch's commits and re-applies them after main's tip, yielding a linear history.
• New hashes: Each replayed commit gets a new SHA-1, because its parent changed.
• Golden rule: Never rebase commits already pushed and shared, as it rewrites history others depend on.
• Contrast with merge: Merge preserves the actual branching graph; rebase fabricates a straight line that is easier to read but hides when work truly diverged.

F. Stashing

Shelves uncommitted changes so the working tree becomes clean.

• Save: git stash stores modified and staged changes and reverts the tree to HEAD.
• Restore: git stash pop re-applies the top stash and removes it; git stash list shows the stack.
• Use case: Switching branches urgently while mid-edit without committing half-finished work.

VI. Git Remote Workflows

Conventions teams adopt to coordinate branching and integration.

A. GitHub Flow

A lightweight, branch-based workflow suited to continuous deployment.

• Single long-lived branch: main is always deployable.
• Cycle: Branch off main → commit → open a Pull Request → review and CI → merge → deploy.
• Anchor: Every merge to main can trigger an automatic deploy, so short-lived branches keep integration frequent.

B. Feature Branch Workflow

Each feature is developed on its own branch off the shared mainline.

• Isolation: A branch named e.g. feature/login contains one unit of work; main never holds broken code.
• Integration: The branch is merged (often via Pull Request) once complete and reviewed, then deleted.
• Contrast with GitHub Flow: GitHub Flow is a feature-branch workflow with the added rule that main is continuously deployable; heavier models (Gitflow) add develop and release branches this one omits.

VII. Resolving Merge Conflicts

Manual reconciliation when automatic merging cannot decide.

A. Cause and Detection

A conflict arises when the same lines are changed differently in the two branches being combined.

• Trigger: Overlapping edits, or one side deleting a file the other modified.
• Detection: Git halts the merge and marks affected files as unmerged (git status lists them).

B. Resolution Procedure

The developer edits the marked regions and completes the merge.

<<<<<<< HEAD
current branch content
=======
incoming branch content
>>>>>>> feature

• Steps: Open each conflicted file, remove the <<<<<<<, =======, >>>>>>> markers, keep the intended lines, then git add the file.
• Finish: git commit (merge) or git rebase --continue (rebase) records the resolution; git merge --abort cancels entirely.

VIII. GitHub Collaboration

Platform features layered on top of Git for team coordination.

A. Issues

Trackable units of work — bugs, tasks, or enhancements.

• Content: Title, description, labels, assignees, and milestones.
• Linking: A commit or PR containing Fixes #12 closes issue 12 automatically on merge.

B. Pull Requests

A proposal to merge one branch into another, wrapped in review tooling.

• Purpose: Compares source and target branches, runs CI checks, and gathers review comments before code enters main.
• Review controls: Required approvals and status checks act as merge gates; the PR records the full discussion as an audit trail.
• Merge modes: Merge commit (preserves history), squash (collapses to one commit), or rebase (linear replay).

C. Discussions

Threaded, forum-style conversations separate from the code.

• Purpose: Q&A, announcements, and open-ended design debate that would clutter issues.
• Distinction: Issues track actionable work with a close state; Discussions host conversation with no expectation of a code change, and can be marked as answered.