Complete Git & GitHub Master Note

Module 1 Introduction to Version Control (Git)

Foundational Architecture

Git is a distributed version control system (DVCS) designed to track code evolution, monitor line-by-line modifications, and preserve reliable snapshots of software systems across teams[cite: 1].

Centralized vs. Distributed Version Control:

• Centralized VCS (e.g., SVN): Versioning operations happen strictly on a central remote server[cite: 1]. If that centralized node goes offline, engineers cannot create new versioned commits or inspect branch history[cite: 1].
• Distributed VCS (Git): Every collaborator clones a complete repository containing the entire historical timeline onto their local machine[cite: 1]. Changes are committed locally first and pushed remotely as needed[cite: 1].

Key Enterprise Advantages:

1. Disaster Resilience: Even if the remote hosting provider suffers an outage, every developer's local clone retains the entire project history and can restore the repository completely[cite: 1].
2. Autonomous Offline Development: You can stage, commit, create branches, and examine logs without internet connectivity.
3. Data Integrity: All files, commits, and tags are cryptographically verified using SHA-1/SHA-256 hashes.

Module 2 Local Configuration & Three-Tree Architecture

1. Global User Identity Configuration

Before recording your first snapshot, establish your global committer identity[cite: 1]:

git config --global user.name "hariprasad"
git config --global user.email "hariiprrawsaad77@gmail.com"
git config --global --list

2. The Three Local States of Git

Git manages tracked modifications through three logical environments:

3. Essential Local Lifecycle Commands

# Initialize tracking inside your project folder
cd /c/Users/Hariiprrawsaad/Desktop/GitPractice
git init

# Inspect working tree status
git status

# Stage untracked or modified files
git add .

# Unstage files without losing local changes
git rm --cached fileName.txt  # Or: git reset fileName.txt

# Commit indexed changes to the local repository
git commit -m "version1: initial setup"

# Review commit history (hash, author, date, message)
git log --oneline

4. File Exclusion with .gitignore

A .gitignore file specifies intentionally untracked patterns (temporary files, build artifacts, and sensitive files) that Git should ignore[cite: 2]:

cat > .gitignore
file1
file2
*.log
node_modules/
.env

Module 3 Branching Strategy, Merging & Rebasing

1. Branch Manipulation Commands

Branches create independent development lines, allowing engineers to build features or isolate bug fixes without destabilizing master[cite: 2].

# List local branches (* shows currently active branch)
git branch

# List all branches including remote-tracking branches
git branch -a

# Create a new branch
git branch develop

# Switch branches
git checkout develop      # Modern alternative: git switch develop

# Create and switch in one execution
git checkout -b feature-1 # Modern alternative: git switch -c feature-1

# Delete a merged branch (safe/soft delete)
git branch -d feature-1

# Force delete an unmerged branch
git branch -D feature-1

2. Merging vs. Rebasing Explained

• Merge (git merge): Unifies branches while retaining the non-linear timeline and recording an explicit merge commit[cite: 5]. Ideal for pulling feature branches into shared integration branches[cite: 5].

  git switch master
  git merge develop

• Rebase (git rebase): Replays your branch commits on top of another base branch, creating a clean, flat, linear history[cite: 5].

  git switch feature-1
  git rebase develop

Module 4 GitHub Remote Operations (Check-In & Check-Out)

1. Connecting Local to Remote (Check-In)

1. Create a blank repository on GitHub[cite: 2].
2. Add the remote tracking origin pointing to the repository URL[cite: 2]:

   git remote add origin https://github.com/AMGOTH011/amgoathh.git

3. Configure a Personal Access Token (PAT):

   GitHub enforces token-based authentication over HTTPS instead of standard account passwords[cite: 2]. Generate a token via Settings > Developer settings > Personal access tokens (classic) with repo permissions[cite: 2].

4. Push your master branch and bind the upstream tracking branch[cite: 2]:

   git push -u origin master

2. Downloading Remote Changes (Check-Out)

• git clone <url>: A one-time initial activity that copies the remote repository and sets up tracking branches[cite: 2, 3].
• git fetch: Downloads remote metadata, commits, and references without updating your working branch[cite: 2, 3].
• git pull: Downloads and merges remote modifications directly into your current working branch (combines fetch + merge)[cite: 2, 3].

Module 5 Advanced Operations: Git Stash, Reset, and Cherry-Pick

1. Git Stash Pop vs. Apply

Stashing saves uncommitted changes temporarily so you can switch branches cleanly without committing unfinished work[cite: 4]:

# Stash indexed and tracked changes
git stash

# Include untracked files in the stash
git stash -u

# Inspect the stack of stashed changes
git stash list

# Re-apply changes and immediately remove them from the stash stack
git stash pop

# Re-apply changes while keeping the stash on the stack for re-use
git stash apply

2. Reset Strategies (Soft, Mixed, Hard) & Commit Recovery

Emergency Disaster Recovery with Reflog: If a destructive reset drops commits unexpectedly, find the prior HEAD reference hash with git reflog and point HEAD back to it[cite: 3, 4]:

git reflog
# Output shows: 9287e3b HEAD@{0}: reset: moving to 9287e3b ... 1a7f614 HEAD@{1}: commit: c
git reset --hard 1a7f614

3. Cherry-Picking & Amending

• Cherry-Pick: Copies a specific commit from one branch directly onto your active branch[cite: 3]:

  git cherry-pick <commit_id>

• Commit Amend: Rewrites the latest commit message or folds recently staged files into the previous commit without creating a duplicate commit[cite: 4]:

  git commit --amend -m "Updated commit message"

• Release Tags: Marks a static reference point in history for production releases[cite: 4]:

  git tag -a v1.0.0 -m "Release version 1.0.0"
  git push origin v1.0.0

Module 6 Automating with GitHub Actions and Webhooks

1. GitHub Actions (CI/CD Pipelines)

GitHub Actions automates testing, build packing, and production deployments directly within your GitHub repository using declarative YAML files stored in .github/workflows/.

Example CI pipeline file (.github/workflows/ci.yml):

name: Enterprise Build & Test Workflow

on:
  push:
    branches: [ "master", "develop" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build-and-verify:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Source Code
        uses: actions/checkout@v4

      - name: Setup Node.js Runtime
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Dependencies and Run Tests
        run: |
          npm ci
          npm test

2. Application Version Packaging & Releases

Deliver tested applications as versioned packages:

• GitHub Releases: Bundles binary files (.jar, .war, .zip, or binaries) with Git release tags.
• GitHub Packages: Serves as a registry for hosting Docker containers, npm modules, and Maven artifacts directly alongside your code.

3. GitHub Webhooks Setup for CI/CD

A Webhook is an automated notification system that sends an HTTP POST payload to an external server (e.g., Jenkins, Slack, or an internal API endpoint) whenever repository events (such as push or pull_request) occur.

Step-by-Step Webhook Setup:

1. Navigate to your GitHub repository and click Settings > Webhooks > Add webhook.
2. Payload URL: Enter your receiver endpoint (e.g., https://ci.mycompany.com/github-webhook/).
3. Content type: Select application/json.
4. Secret: Provide a shared secret key to cryptographically verify payload origin.
5. Trigger Events: Choose Just the push event or customize by selecting specific events (Pull Requests, Releases).
6. Check Active and click Add webhook to start receiving event notifications.