Git Distributed Version Control & Branch Management – Detailed Study Notes

Opening Invocation & Class Context

• Session began with a prayer asking for divine guidance, wisdom and understanding; reference to Zechariah 4:6 ("not by might, nor by power, but by My Spirit").
• Lecturer (“Prof /Lega”) thanks students for watching the previous lesson video; checks participation via chat.

Big-Picture Purpose of the Course

• Goal: develop mastery of Git and Source-Code Management (SCM) so we can support DevOps pipelines (develop → test → build → deploy → monitor).
• As DevOps engineers we do NOT write application code, but we must:
  • Provision & secure developers’ environments (AWS/GCP VMs, IDEs, Git installation, etc.).
  • Create & manage SCM accounts (GitHub orgs, teams, repos, access levels).
  • On-board projects, set permissions (read / write / admin).
  • Facilitate versioning, collaboration, automation and roll-back.

Why Version Control?

• Every application release is a version.
• Clients expect roll-backs (e.g., revert from version 3 to version 2 if v3 misbehaves).
• Manual/local versioning drawbacks:
  • Single point of failure (laptop crash ⇒ entire history lost).
  • No collaboration; resource inefficiency; delayed rollback.
• Centralised VCS (single server) mitigates some issues but still has SPOF.
• Distributed VCS (DVCS) solves the above: every clone carries full history, enabling offline work, integrity checks, easy branching, and rapid operations.

Git in the Industry

• Git = DVCS that stores snapshots not file diffs.
• Core benefits:
  • Nearly every operation is local → speed.
  • Data integrity via checksums (SHA-1/2 hash IDs).
  • Append-only model → history cannot be silently altered.
• Alternative DVCS tools: Subversion, CVS, TFVC, etc.
• Adoption metrics: $95\%$ of companies use Git; $80\%$+ host on GitHub.
  • Real-estate metaphor: If 70 tenants fight for 5 remaining flats, that property must be attractive ⇒ choose GitHub when 8/10 companies already do.

Source-Code Management (SCM) Hosting Choices

• GitHub (dominant), GitLab, Bitbucket, AWS CodeCommit…
• In class we standardise on GitHub.

Installation Checklist

• Windows: download Git installer → Git Bash provides POSIX-like CLI.
• Linux (RHEL, CentOS, Amazon Linux): sudo yum install git -y.
• Confirm with git --version.
• Configure global identity once per workstation:

  git config --global user.name  "Simon Lega"
  git config --global user.email "simon@example.com"

Core Git Areas & Vocabulary

Frequently-Used Git Commands

• git init – initialise empty repo (creates default master branch).
• git status – show file states.
• git add <file> / git add . – stage changes.
• git commit -m "msg" – record snapshot to local repo.
  • Shortcut for modified files only: git commit -a -m "msg" (auto-adds).
• git log – list commit history.
• git show <sha> – view details/diff of one commit.
• git remote add <alias> <url> – link local repo to remote; common alias origin but any (e.g., pp).
• git push <alias> <branch> – upload commits.
• git remote -v – list configured remotes.
• git branch – list branches; git branch <name> create; git switch <name> move.
• git diff <branchA> <branchB> – compare two branches.
• git merge <branch> – integrate another branch into current.
• git fetch – download updates to local repo only.
• git pull – fetch + merge into working dir.
• git clone <url> – initial copy of entire repo.

Hands-On Walkthrough (CLI)

1. Create folder & repo

   mkdir paper && cd paper
   git init   # → master branch

2. Add file list with names; stage & commit

   echo "Simon" >  list
   echo "Paul"  >> list
   git add list
   git commit -m "first commit"

3. Modify, commit again (James added), view history with git log & git show.
4. Connect to GitHub

   git remote add pp https://github.com/landmarktechnology/paper34.git
   git push pp master   # prompts for username + PAT token

• Password deprecated ⇒ create Personal Access Token (PAT) under Settings → Developer Settings → PAT (Classic) (e.g., 90-day expiry, repo scope).

1. Further modification (Chidinma), demonstrate git commit -a -m (works only on modified files, not new ones).
2. Add new script deploy.sh, illustrate need for 2-step add→commit.
3. Show push of multiple commits; GitHub now displays 4 commits.

Branching Fundamentals

• Branch = independent line of development.
• Default branch master is created on git init.
• Create dev/stage branches:

  git branch development
  git branch stage

• Branch pointer relationships: if development originates from master, then master is upstream of development.
• Switching & isolation example:
  • In development, add new file app.java.
  • Switch back to master → file not present until merged.

Merge & Pull-Request Workflow (GitHub UI)

1. Developer pushes branch stage.
2. GitHub shows "Compare & Pull Request".
3. Reviewer(s) (e.g., Abby, Ken, Lega) assigned.
4. Add description, discuss in comments.
5. If no conflicts, click Merge pull request → changes land in master.
6. Delete branch if no longer needed.

Merge Conflicts & Manual Resolution

• Scenario: both stage and master modify same line in list.
• Attempt git merge stage inside master → conflict markers <<<<<<<, =======, >>>>>>> appear.
• Steps to fix:
  1. vi list → keep correct lines, delete markers.
  2. git add list (or commit -a -m "conflict resolved").

Fetch vs Pull vs Clone

Sequence when cautiously updating:

git fetch pp master   # download
git diff pp/master    # inspect changes
git merge pp/master   # apply if satisfied

Equivalent quick path:

git pull pp master

Branching Strategy Adopted in Class

• Maintain minimum three long-lived branches:
  • development → deployed to DEV environment.
  • stage (or testing/UAT) → deployed to STAGE / UAT environment.
  • master (a.k.a. main) → deployed to PRODUCTION.
• Short-lived auxiliary branches created off master then deleted after merge:
  • feature/<name> – new feature work (e.g., touch-pay integration).
  • hotfix/<name> or bugfix/<name> – urgent prod fixes.

Real-World Metaphors Used

• Snapshots = photos: yearly baby pictures illustrate Git storing complete images of state.
• Property rental: choosing Git is like choosing a popular apartment complex—market demand signals quality.
• Carpentry for workspace areas: workshop (working), showroom (staging), warehouse (local repo), logistics hub (remote).

Upcoming Topics Mentioned

• Cleaning a dirty working directory: git clean, git reset, git revert.
• Cron-job demo (prior lecture) wrote output to “/dev/null” (bit-bucket): explains why nothing visible.

Ethical / Practical Notes

• Always use clear, descriptive commit messages to aid future audits.
• Only senior/reviewer roles approve PRs; junior devs should not merge unreviewed code.
• Never deploy directly from feature/hotfix branches; merge into master first.

Numerical / Statistical References

• $95\%$ companies use Git.
• $80\%$+ use GitHub.
• Real-estate example: 50 units, 5 vacant, 70 applicants → green flag.

Class Logistics & Announcements

• Next live session Thursday skipped due to US Thanksgiving; recorded video will be provided.
• Q&A covered:
  • How to git add directories (yes, supported).
  • Why pull from master (most secure, latest validated code).
  • Separation of responsibilities among junior devs, senior devs, DevOps.

Quick Reference Cheat-Sheet

# Initialise & first commit
git init
git add .
git commit -m "initial"

# Connect & push
git remote add origin <url>
git push -u origin master

# Create / switch / delete branch
git branch dev
git switch dev   # or: git checkout dev
git branch -d feature32   # delete local branch

git pull origin master    # sync with remote

# Resolve conflict markers
<<<<<<< HEAD
current change
=======
incoming change
>>>>>>> stage

Take-Away Points

• Understand the four Git areas and how commands move snapshots between them.
• Adopt the dev → stage → master branching model for CI/CD pipelines.
• Use pull requests for every integration; enforce review/approval.
• PAT tokens replace passwords for GitHub HTTPS pushes.
• Practice resolving merge conflicts—unavoidable in real collaboration.