Git, GitHub & GitHub Actions for CI/CD

Before diving into Git and GitHub, make sure you have a few basics in place. Think of this like gathering ingredients before cooking — you don't need to be an expert chef, but you do need a kitchen.

What You Should Know

• Basic computer skills — creating folders, installing software, using a text editor.
• Command line comfort (helpful, not required) — we'll show you the commands, but GUI tools like GitHub Desktop exist if you prefer clicking over typing.
• A free GitHub account — sign up at github.com.

Tools to Install

git --version

[[VISUAL_PLACEHOLDER: Diagram showing the developer toolchain — editor, terminal with Git, browser with GitHub, all connected by arrows]]

First-Time Git Configuration

Git needs to know who you are so it can label your work. Run these once after installing Git:

# Tell Git your name and email
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Set default branch name to 'main'
git config --global init.defaultBranch main

Imagine you're baking cookies for a bake sale. Every time you change the recipe, you'd taste-test before selling — that's quality checking. If the cookies pass, you'd box them up and deliver them — that's delivery. CI/CD automates both steps for software.

[[VISUAL_PLACEHOLDER: CI/CD pipeline flowchart — Developer pushes code → CI runs tests → CD deploys to server → Users see update]]

Why Teams Use CI/CD

• Catch bugs faster — broken code is detected within minutes, not days.
• Ship confidently — if the pipeline is green, you know the basics work.
• Reduce manual work — no more "works on my machine" deploy rituals at 2 AM.
• Enable collaboration — many developers can work in parallel without stepping on each other.

Where Git, GitHub & Actions Fit In

Git tracks every change to your code. GitHub hosts that history online and lets teams collaborate. GitHub Actions is GitHub's built-in automation engine — it watches for events (like a push) and runs your CI/CD pipeline in the cloud.

Git is a version control system. Think of it as an unlimited "Undo" button for your entire project — but smarter. Instead of one undo, Git saves a timeline of every saved state (called a commit), who made it, and why.

[[VISUAL_PLACEHOLDER: Timeline diagram showing commits as dots on a line, each labeled with a message and author]]

Key Concepts

[[VISUAL_PLACEHOLDER: Three-box diagram — Working Directory, Staging Area, Repository — with arrows labeled git add and git commit]]

Essential Commands

# Create a new repo in the current folder
git init

# Check what's changed
git status

# Stage a file
git add index.html

# Commit with a message
git commit -m "Add landing page"

# View commit history
git log --oneline

If Git is the engine, GitHub is the garage where you park and share your project. It's a website (and much more) that stores Git repositories online, adds collaboration tools, and connects to automation like GitHub Actions.

[[VISUAL_PLACEHOLDER: Illustration comparing local Git repo on a laptop vs. remote GitHub repo in the cloud, connected by sync arrows]]

Local vs. Remote

• Local repository — lives on your computer. Fast, works offline.
• Remote repository — lives on GitHub's servers. Backed up, shareable, triggers CI/CD.
• Origin — the default name for your primary remote on GitHub.

Creating & Connecting a Repo

# On GitHub: click "New repository", then locally:
git remote add origin https://github.com/username/my-project.git
git push -u origin main

Core GitHub Features

Day-to-day GitHub work is a rhythm: pull the latest changes, make edits, commit locally, then push back to GitHub. It's like borrowing a shared notebook, writing your page, and returning it to the shelf.

[[VISUAL_PLACEHOLDER: Sync cycle diagram — pull down → edit → commit → push up, looping between local and remote]]

Clone an Existing Project

git clone https://github.com/username/project.git
cd project

This downloads the entire history — not just the latest files — so you have the full timeline locally.

Daily Sync Commands

# Get latest changes from GitHub
git pull origin main

# Send your commits to GitHub
git push origin main

Handling Merge Conflicts

A merge conflict happens when two people edit the same lines differently. Git pauses and asks you to pick the correct version. Open the conflicted file, look for markers like <<<<<<<, choose the right code, then commit the resolution.

[[VISUAL_PLACEHOLDER: Side-by-side diff view showing conflict markers and resolved merge]]

A branch is an independent line of development. Imagine writing a draft chapter in a separate notebook while the published book stays untouched. When the draft is ready, you merge it back into the main story.

[[VISUAL_PLACEHOLDER: Branch diagram — main branch as a straight line, feature branch splitting off and merging back]]

Branch Workflow

# Create and switch to a new branch
git checkout -b feature/login-page

# ... make changes, commit ...

# Push branch to GitHub
git push -u origin feature/login-page

# Switch back to main
git checkout main

Naming Conventions

• feature/add-search — new functionality
• fix/broken-navbar — bug fixes
• docs/update-readme — documentation only

A Pull Request (PR) is a formal proposal: "Here are my changes — please review before merging into main." It's the heart of team collaboration on GitHub, and it's where CI pipelines often run automatically.

[[VISUAL_PLACEHOLDER: Pull request UI mockup showing changed files, review comments, and CI check status]]

The PR Lifecycle

1. Create a branch and push your commits.
2. Open a Pull Request on GitHub, describing what and why.
3. Automated CI checks run (tests, linting, build).
4. Teammates review code and leave comments.
5. Once approved and checks pass, merge into main.
6. Delete the feature branch — it's served its purpose.

Writing Good PR Descriptions

Include context a reviewer needs: the problem you're solving, how you solved it, and how to test it. Link related issues with keywords like Fixes #42 to auto-close them on merge.

GitHub Actions lets you automate tasks when things happen in your repository — push code, open a PR, schedule a cron job. GitHub spins up a temporary virtual machine (called a runner), runs your instructions, and reports pass/fail.

[[VISUAL_PLACEHOLDER: GitHub Actions architecture — Event triggers Workflow → Jobs → Steps on Runners]]

Core Terminology

Hello World Workflow

# .github/workflows/hello.yml
name: Hello CI
on: [push]
jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Hello from GitHub Actions!"

A CI pipeline typically: checks out your code, installs dependencies, runs linters, runs tests, and maybe builds the project. If any step fails, the workflow turns red and the PR is blocked from merging.

[[VISUAL_PLACEHOLDER: CI pipeline stages — Checkout → Install → Lint → Test → Build, with pass/fail indicators]]

Example: Node.js CI

name: Node CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Matrix Builds

Test across multiple versions simultaneously using a strategy matrix. For example, run tests on Node 18 and Node 20 in parallel — catching version-specific bugs early.

Once CI passes, Continuous Deployment takes over — automatically publishing your site or app. GitHub Pages is perfect for static sites (HTML, CSS, JS) like this very tutorial.

[[VISUAL_PLACEHOLDER: CD flow — merge to main → Actions deploy job → GitHub Pages URL goes live]]

Deploy with GitHub Actions

name: Deploy to Pages
on:
  push:
    branches: [main]
permissions:
  contents: read
  pages: write
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/upload-pages-artifact@v3
        with:
          path: '.'
      - uses: actions/deploy-pages@v4

Environments & Approvals

For production deploys, use GitHub Environments with required reviewers. Staging can auto-deploy; production waits for a human to click "Approve."

Secrets in CI/CD

Never hardcode API keys in workflow files. Store them in Repository Secrets (Settings → Secrets → Actions) and reference them as ${{ secrets.MY_KEY }}.

[[VISUAL_PLACEHOLDER: Secrets flow diagram — encrypted in GitHub Settings, injected at runtime into workflow, never logged]]