## Session Start
On every session start: read HANDOFF_AGENTS.md if present, then wait for user direction.
+## Git Workflow
+All content work (articles, updates, assets) commits to feature branches or `master`. Never push directly to the `production` branch. The user merges `master` → `production` when ready to deploy to the live site.
+
## Directory Structure
```
content/
- Theme repo: `~/Programming/GIT/danix2-hugo-theme/` → `danix_git:danix2-hugo-theme`
- Theme lives as submodule at `themes/danix-xyz-hacker/` in content repo
+**Three branches, defined roles:**
+- `master`: staging/dev branch. All feature branches merge here. Safe for WIP commits and testing.
+- `production`: live branch. Merges only from master when ready to ship. Post-receive hook fires on production pushes only.
+- Feature branches: work branches for features, content, or experiments. Merge to master when done.
+
**Theme work:**
1. Edit in theme repo OR submodule (always `git checkout master` first if using submodule)
2. Commit and push to `danix2-hugo-theme`
2. Commit compiled CSS in theme: `cd themes/danix-xyz-hacker && git add assets/css/main.min.css && git commit -m "build: recompile CSS" && git push origin master`
3. Bump submodule: `cd .. && git add themes/danix-xyz-hacker && git commit -m "chore: bump theme submodule (CSS rebuild)" && git push origin master`
-**Deployment:**
-- Production hook clones latest `danix2-hugo-theme` master tip on each content push
-- Theme changes deploy automatically on next content push (no submodule bump required for deployment, only for local tracking)
+**Deployment to production:**
+1. When master is ready to ship: `git checkout production && git merge master && git push origin production`
+2. Post-receive hook clones latest `danix2-hugo-theme` master tip and builds the site
+3. Theme changes deploy automatically on next production push (no submodule bump required for deployment, only for local tracking)
## 🎨 Styling & Build Pipeline
- **Tailwind CSS**: Uses npm build pipeline with `tailwind.config.js`
---
+## Branches
+
+Three branches govern the site:
+
+| Branch | Purpose | Push Triggers Deploy |
+|--------|---------|---------------------|
+| `master` | Staging/dev. Feature branches merge here. Safe for WIP. | No |
+| `production` | Live branch. Merges from master only, when ready to ship. | **Yes** |
+| `feature/*` or `week-*-*` | Work branches. Merge to master when done. | No |
+
## Working on Content
-All content work happens in `~/Programming/GIT/danix.xyz-hacker-theme/`.
+All content work happens in `~/Programming/GIT/danix.xyz-hacker-theme/`, committed to a feature branch or directly to `master`. Master does not trigger deploy — only `production` does.
### Add a new article
# write the article, add images to the same directory
git add content/en/articles/my-new-article/
git commit -m "content: add article 'my-new-article'"
-git push origin master
+git push origin master # or push feature branch
```
### Edit an existing article
## Production Deployment
-Pushing to `danix_git:danix.xyz-2` (master) triggers the `post-receive` hook on the server.
+Pushing to the `production` branch triggers the `post-receive` hook on the server.
+
+```bash
+git checkout production
+git merge master # bring production up to date with master
+git push origin production
+```
The hook:
1. Creates a fresh Hugo site in `/tmp/danix.xyz-compile`
-2. Checks out the content repo there
+2. Checks out the content repo at `production` branch
3. Clones the **latest tip of `danix2-hugo-theme` master** into `themes/dagreynix`
4. Runs `hugo -t dagreynix --minify`
5. Publishes to `/var/www/html`
**Important:** The hook always clones the current tip of the theme repo — it does NOT use the submodule pointer. This means:
-- Pushing a theme change to `danix_git:danix2-hugo-theme` is enough for production to pick it up on the next content deploy.
+- Pushing a theme change to `danix_git:danix2-hugo-theme` is enough for production to pick it up on the next production deploy.
- You do NOT need to bump the submodule pointer to deploy theme changes. The pointer is for local tracking only.
-- If you want to deploy a theme change immediately without a content change, make any trivial commit in the content repo and push it.
+- If you want to deploy a theme change immediately without a content change, merge master to production and push (even if no content changed).
---
## Quick Reference
```
-# content change → deploy
+# content change → staging (master)
cd ~/Programming/GIT/danix.xyz-hacker-theme
git add <files> && git commit -m "..." && git push origin master
-# theme change → deploy
+# content/config → production (deploy to live)
+cd ~/Programming/GIT/danix.xyz-hacker-theme
+git checkout production && git merge master && git push origin production
+
+# theme change → staging, then production
cd ~/Programming/GIT/danix2-hugo-theme # or themes/danix-xyz-hacker/
git checkout master
git add <files> && git commit -m "..." && git push origin master
-# then bump pointer:
+# then bump pointer and push to master:
cd ~/Programming/GIT/danix.xyz-hacker-theme
git add themes/danix-xyz-hacker && git commit -m "chore: bump theme" && git push origin master
+# then deploy to production:
+git checkout production && git merge master && git push origin production
# check submodule status
git submodule status
-# Weekly Branching Policy
+# Branching Policy
-**Effective Date:** Week 3 (2026-04-17 onwards)
+**Effective Date:** 2026-04-28 (production branch added)
**Status:** ✅ Active
---
## Executive Summary
-Starting with Week 3, each week of implementation work will use a **feature branch** to isolate changes, enable code review, and ensure safe integration into the main `master` branch.
+All work uses feature branches or direct commits to `master` (staging). `production` branch is the deploy target — only merge from `master` when ready to ship to live site. No direct commits to `production`.
-**Format:** `week-<number>-<description>`
-**Example:** `week-3-cards-nav`, `week-4-forms-interactions`
+**Format for feature branches:** `week-<number>-<description>`, `feature/*`, or other descriptive names
+**Example:** `week-3-cards-nav`, `feature/dark-mode`, `content/about-page-rewrite`
---
-## Why Weekly Branching?
+## Branch Roles
-### 1. Code Review
-Each week's work can be reviewed as a complete unit before merging to master.
+| Branch | Purpose | Deploy |
+|--------|---------|--------|
+| `master` | Staging/dev. Feature branches merge here. WIP and testing ok. | No |
+| `production` | Live branch. Merges from master only when ready to ship. Protected. | **Yes** |
+| Feature branches | Work branches. Merge to master when done. | No |
-### 2. Safety
-If issues are discovered, the feature branch can be easily discarded without affecting master. Easy rollback if needed.
+---
+
+## Why This Approach?
+
+### 1. Safety
+`production` is protected from accidental pushes. Only intentional merges from master deploy to live.
+
+### 2. Staging
+`master` allows free commits, testing, and experimentation without risk of live deployment.
### 3. Isolation
-Each week's work is independent. Less chance of accidental changes or conflicts affecting master.
+Feature branches isolate large work, experiments, and reviews before master.
-### 4. Clean History
-Git log shows logical, week-based commits instead of intermingled changes.
+### 4. Flexibility
+Small, quick changes can go directly to master. Larger work uses branches.
-### 5. Testing
-Entire week's work can be tested on the feature branch before merging. Catch issues before they affect master.
+### 5. Deployment Control
+Merge to `production` only when you've tested and are ready. One extra step prevents accidents.
---
-## Weekly Workflow
+## Workflow
-### Week 3 (and beyond)
+### Feature Branch + Staging + Production
```
-┌─── master (stable, always works)
+┌─── feature/my-feature (development)
+│ ├─ commit 1: initial implementation
+│ ├─ commit 2: fixes and tweaks
+│ └─ [TESTED LOCALLY]
+│
+├─ Merge to master (staging)
+│ └─ master now has changes, no deploy yet
│
-├─ week-3-cards-nav (feature branch)
-│ ├─ commit 1: add card component
-│ ├─ commit 2: add navigation header
-│ ├─ commit 3: add hamburger menu
-│ ├─ commit 4: add breadcrumbs
-│ └─ [TESTED & REVIEWED]
+└─ When ready to ship:
+ └─ Merge master → production (triggers live deploy)
+```
+
+OR for quick fixes/content:
+
+```
+┌─── master (quick commits directly)
+│ ├─ commit 1: fix typo
+│ ├─ commit 2: update article
+│ └─ [TESTED]
│
-└─ Merge to master when ready
- └─ master now has Week 3 changes
+└─ When ready: merge master → production (triggers deploy)
```
---
## Step-by-Step Instructions
-### 1. Start of Week
+### 1. For Feature Branches
```bash
# Ensure master is up to date
git checkout master
-git pull origin master # if using remote
+git pull origin master
# Create feature branch
-git checkout -b week-3-cards-nav
+git checkout -b feature/my-feature
+# or: git checkout -b week-5-new-feature
-# Verify branch created
-git branch -v
+# Make changes, test, commit
+vim content/en/articles/new-article/index.md
+npm run build # if changing CSS/templates
+git add .
+git commit -m "feat: add new feature"
+
+# Test thoroughly on this branch
+hugo server
```
-### 2. Throughout the Week
+### 2. For Quick Changes
```bash
-# Make changes (CSS, templates, docs)
-vim themes/danix-xyz-hacker/assets/css/main.css
+# Small fixes, typos, content updates can go straight to master
+git checkout master
+git pull origin master
-# Rebuild CSS
-npm run build
+# Make changes (CSS, templates, docs, content)
+vim content/en/articles/existing/index.md
-# Test in browser
-hugo server
+# Rebuild CSS if needed
+npm run build
-# Commit regularly after each component
+# Commit
git add .
-git commit -m "feat: add article card component"
+git commit -m "content: fix typo in article"
-# Commit again when next component done
-git add .
-git commit -m "feat: add navigation header"
+# Push to master
+git push origin master
```
-### 3. End of Week (Before Merging)
+### 3. Before Merging Branch to Master
```bash
# Review all changes
-git diff master..week-3-cards-nav
+git diff master..feature/my-feature
# Review commit history
-git log master..week-3-cards-nav --oneline
+git log master..feature/my-feature --oneline
# View file changes summary
-git diff --stat master..week-3-cards-nav
+git diff --stat master..feature/my-feature
-# Test thoroughly in browser
-# - All dark mode
-# - All light mode
+# Test thoroughly
+hugo server
+# - All dark/light modes
# - Mobile, tablet, desktop
# - Keyboard navigation
# - All interactive elements
# Check CSS builds without errors
npm run build
-# Check for console errors in browser
-# (DevTools → Console)
-
-# Check git log looks good
-git log --oneline -10
+# Check for console errors
```
### 4. Merge to Master
-Once testing is complete:
-
```bash
# Switch to master
git checkout master
+git pull origin master
# Merge feature branch
-git merge week-3-cards-nav
+git merge feature/my-feature
# Optional: Delete feature branch
-git branch -d week-3-cards-nav
+git branch -d feature/my-feature
-# Verify merge
+# Verify and push
git log --oneline -5
+git push origin master
```
-### 5. Start Next Week
+### 5. Deploy to Production
```bash
-# Create next week's branch
-git checkout -b week-4-forms-interactions
+# When master is ready to go live
+git checkout production
+git pull origin production
+
+# Merge master into production
+git merge master
+
+# This triggers the live deploy
+git push origin production
-# Continue with Week 4 work...
+# Verify deployment complete (check server log or website)
```
---
-## Branching Policy Details
+## Policy Details
-### Branch Creation
+### Feature Branch Creation
- **Source:** Always branch from `master`
-- **Timing:** At the start of each week
-- **Naming:** `week-<N>-<description>` (lowercase, hyphens)
+- **Naming:** `feature/*`, `week-*`, `content/*`, or descriptive names (lowercase, hyphens)
+- **Lifetime:** Keep it reasonable — days to weeks, not months
Examples:
```
-week-3-cards-nav
-week-4-forms-interactions
-week-5-animations-a11y
-week-6-pages-testing
+feature/dark-mode
+week-5-forms
+content/new-article
+fix/layout-bug
```
-### Commits During Week
+### Commits
-- **Frequency:** Commit after each component is complete
-- **Messages:** Clear, descriptive, following format
-- **Size:** Small, logical chunks (not one big commit)
+- **Frequency:** Commit regularly, after each logical unit of work
+- **Messages:** Clear, descriptive, following the format from GIT-WORKFLOW.md
+- **Size:** Small chunks (not one giant commit), but not one-commit-per-line either
-Example commits for Week 3:
+Example commit sequence:
```
-feat: add article card component
-feat: add card hover effects (lift, shadow)
-feat: add navigation header
-feat: add hamburger menu
-feat: add breadcrumb navigation
-docs: week 3 implementation complete
+feat: add contact form component
+feat: add form validation
+fix: fix button styling in dark mode
+docs: update contact form documentation
```
### Testing Before Merge
- [ ] Color contrast WCAG AA verified
- [ ] All interactive components working (buttons, menus, etc.)
-### Merge to Master
+### Master Branch
-**Before merging:**
-1. Review all changes: `git diff master..week-N-...`
-2. Complete testing checklist above
-3. Verify git log is clean and clear
+- **No direct deploys.** Master is staging only.
+- **Safe to commit to directly** for small fixes, typos, content updates.
+- **Use feature branches** for significant work (theme, layout, major features).
+- **No WIP or broken code** — master should always build without errors.
-**Merge command:**
-```bash
-git checkout master
-git merge week-N-...
-```
+### Production Branch
-**After merge:**
-1. Delete feature branch: `git branch -d week-N-...`
-2. Verify all changes are in master: `git log --oneline -10`
-3. Start next week's branch
+- **Protected.** Never commit directly. Only merge from master.
+- **Deploy trigger.** Every push to production triggers the live rebuild.
+- **Deploy command:**
+ ```bash
+ git checkout production
+ git merge master
+ git push origin production
+ ```
+- **One-way merge.** Only master → production. Never production → master.
---
-## Retroactive Application
+## FAQ
+
+### "Can I commit directly to master?"
+Yes, for small fixes, typos, and content updates. For theme work, features, or larger changes, use a branch.
+
+### "What if I commit to master and it breaks something?"
+Master should always build. If it breaks, fix it immediately (either in another commit or revert). Do not push broken code to production.
+
+### "Do I have to use 'week-*' branches?"
+No. `week-*` is just a naming convention. Use `feature/*`, `content/*`, `fix/*`, or any descriptive name.
-**Weeks 1-2** were completed on `master` before this policy was adopted.
+### "Can I create sub-branches off a feature branch?"
+Generally no. Use clear commit messages for isolation. If you really need to branch off a branch, just keep it simple.
-**Week 3 onwards** will follow weekly branching policy.
+### "What if there's an urgent bug during a feature branch?"
+Fix it on the feature branch (if it's part of the work), or fix it on master separately, then merge into the feature branch. Never push a broken feature branch to production.
-All Week 3+ work will be properly isolated on feature branches.
+### "How do I deploy to production?"
+Merge master → production and push:
+```bash
+git checkout production && git merge master && git push origin production
+```
---
# Git Workflow Quick Reference
-## Before Each Week
+## Three Branches
-```bash
-# Create feature branch
-git checkout -b week-3-cards-nav
+| Branch | Purpose | Deploy |
+|--------|---------|--------|
+| `feature/*`, `week-*` | Development | No |
+| `master` | Staging/dev | No |
+| `production` | Live | **Yes** |
+
+## Create Feature Branch (Optional)
-# Verify you're on the new branch
+```bash
+git checkout -b feature/my-feature
+# or: git checkout -b week-5-forms
git branch -v
```
-## During the Week
+## During Development
```bash
# Check status
# See what changed
git diff
-# Stage files for commit
-git add themes/danix-xyz-hacker/assets/css/main.css
-git add themes/danix-xyz-hacker/layouts/partials/card.html
+# Stage and commit
+git add <files>
+git commit -m "feat: add component"
-# Commit regularly
-git commit -m "feat: add article card component with hover effects"
-
-# Rebuild CSS
+# Rebuild CSS if changed templates
npm run build
-# Test in browser
+# Test
hugo server
```
-## Common Commands
+## Review Changes
```bash
# View recent commits
git log --oneline -10
# View all changes since master
-git diff master..week-3-cards-nav
-
-# View specific file changes
-git diff master..week-3-cards-nav themes/danix-xyz-hacker/assets/css/main.css
+git diff master..feature/my-feature
-# Undo last commit (keep changes)
-git reset --soft HEAD~1
+# View changes summary
+git diff --stat master..feature/my-feature
+```
-# Undo last commit (discard changes)
-git reset --hard HEAD~1
+## Merge to Master (Staging)
-# Switch between branches
+```bash
git checkout master
-git checkout week-3-cards-nav
+git pull origin master
+git merge feature/my-feature
+git branch -d feature/my-feature # optional
+git push origin master
```
-## At End of Week
+## Deploy to Production (LIVE)
```bash
-# Review all changes
-git diff master..week-3-cards-nav
+git checkout production
+git pull origin production
+git merge master
+git push origin production
+# ← This triggers the live rebuild
+```
-# Review summary
-git diff --stat master..week-3-cards-nav
+## Common Commands
-# Review commit history
-git log master..week-3-cards-nav --oneline
+```bash
+# Undo last commit (keep changes)
+git reset --soft HEAD~1
-# Test thoroughly in browser
-# - Dark mode
-# - Light mode
-# - Mobile (320px)
-# - Tablet (768px)
-# - Desktop (1060px+)
-# - Keyboard nav (Tab, Enter, Escape)
-# - All interactive components
+# Undo last commit (discard changes)
+git reset --hard HEAD~1
-# Merge to master
+# Switch branches
git checkout master
-git merge week-3-cards-nav
+git checkout feature/my-feature
-# Delete feature branch
-git branch -d week-3-cards-nav
-
-# Verify merge
-git log --oneline -5
+# Rebase feature branch on latest master (optional)
+git checkout feature/my-feature
+git rebase master
```
## Commit Message Template
```
-feat: add article card component
+feat: add contact form component
-- Image with 16:9 aspect ratio
-- Title, excerpt, badge, button
-- Hover: lift -2px, shadow enhancement
+- Form validation
- Dark/light mode support
-- Mobile-first responsive design
+- WCAG AA accessibility
```
## Key Points
-✅ Create feature branch at start of week
-✅ Commit regularly (after each component)
-✅ Use clear commit messages
-✅ Test before end of week
-✅ Review all changes before merging
-✅ Merge to master when ready
-✅ Delete feature branch after merge
-✅ Repeat for next week
+✅ Feature branch or quick master commits
+✅ Commit regularly after logical units
+✅ Clear commit messages
+✅ Test in browser before merging
+✅ Merge feature → master (staging)
+✅ Merge master → production (LIVE DEPLOY)
## For Full Details
-See `GIT-WORKFLOW.md` for comprehensive workflow documentation.
-
+See `GIT-WORKFLOW.md` for comprehensive documentation.
-# Git Workflow Guide — Weekly Branching
+# Git Workflow Guide
-**Effective Date:** 2026-04-16
-**Policy:** Each week of implementation work starts on a new feature branch for code review and safe integration.
+**Effective Date:** 2026-04-28 (production branch added)
+**Policy:** Feature branches merge to `master` (staging). `production` branch is the live deploy target.
---
## Overview
-### Why Weekly Branching?
+### Three Branches
-1. **Code Review** — Review all changes for a week before merging to master
-2. **Safety** — Easy to rollback if issues are discovered
-3. **Isolation** — Each week's work is independent, reducing merge conflicts
-4. **History** — Clean git log with logical week-based commits
-5. **Testing** — Test entire week's work on feature branch before merging
+| Branch | Purpose |
+|--------|---------|
+| `feature/*`, `week-*` | Development branches. Merge to master when done. |
+| `master` | Staging/dev. No deploy hook. Safe for testing and WIP. |
+| `production` | Live. Triggers deploy. Only merge from master when ready. |
-### Branch Naming Convention
+### Workflow
```
-week-<number>-<description>
+Feature branch (develop, test)
+ ↓
+ Merge to master (staging, review)
+ ↓
+ Merge to production (LIVE DEPLOY)
```
-Examples:
-- `week-3-cards-nav` (Week 3: Cards & Navigation)
-- `week-4-forms-interactions` (Week 4: Forms & Interactive Elements)
-- `week-5-animations-a11y` (Week 5: Animations & Accessibility)
-- `week-6-pages-testing` (Week 6: Missing Pages & End-to-End Testing)
+### Branch Naming
+
+- Feature branches: `feature/*`, `week-*`, `content/*`, `fix/*`
+- Examples: `feature/dark-mode`, `week-5-forms`, `content/article-update`, `fix/button-style`
---
-## Weekly Workflow
+## Feature Branch Workflow
-### Step 1: Create Feature Branch
+### Step 1: Create Feature Branch (Optional)
-At the start of each week, create a new feature branch from `master`:
+For significant work, create a feature branch:
```bash
# Ensure you're on master and up to date
git checkout master
-git pull origin master # (if using remote)
+git pull origin master
# Create feature branch
-git checkout -b week-3-cards-nav
+git checkout -b feature/my-feature
+# or: git checkout -b week-5-forms
# Verify branch created
git branch -v
```
-Output should show:
-```
- master abc1234 commit message
-* week-3-cards-nav abc1234 commit message
-```
-
-The `*` indicates you're on the new branch.
+### Step 2: Implement Changes
-### Step 2: Implement Week's Work
-
-While on the feature branch, implement all changes for the week:
+While on the feature branch, implement all changes:
```bash
-# Make changes to CSS, templates, documentation
+# Make changes to CSS, templates, content, docs
vim themes/danix-xyz-hacker/assets/css/main.css
-vim themes/danix-xyz-hacker/layouts/partials/...
+vim content/en/articles/new-article/index.md
# Rebuild CSS after changes
npm run build
# Check what changed
git status
-git diff themes/danix-xyz-hacker/assets/css/main.css
+git diff
```
### Step 3: Commit Regularly
- Mobile-first responsive design"
```
-### Step 4: Daily Progress Tracking
-
-Update memory at end of each day during the week:
-
-```bash
-# Create/update memory file
-cat > /path/to/.claude/projects/.../memory/week3_progress.md << 'EOF'
-# Week 3 Progress
-
-**Date:** 2026-04-17
-**Status:** In progress (Day 1)
-
-## Completed Today
-- [x] Article card CSS
-- [x] Card integration into templates
-- [x] Responsive testing
-
-## Tomorrow
-- [ ] Navigation header
-- [ ] Hamburger menu
-EOF
-
-git add memory/week3_progress.md
-git commit -m "docs: update week 3 progress (day 1)"
-```
-
-### Step 5: Review Changes at End of Week
+### Step 4: Review Changes Before Merge
-Before merging back to master, review all changes:
+Before merging to master, review all changes:
```bash
-# Show all commits in this week
-git log master..week-3-cards-nav --oneline
+# Show all commits in this branch
+git log master..feature/my-feature --oneline
# Show all file changes (diff summary)
-git diff --stat master..week-3-cards-nav
+git diff --stat master..feature/my-feature
-# Show detailed diff for CSS
-git diff master..week-3-cards-nav themes/danix-xyz-hacker/assets/css/main.css
+# Show detailed diff for critical files
+git diff master..feature/my-feature
-# Show detailed diff for specific template
-git diff master..week-3-cards-nav themes/danix-xyz-hacker/layouts/partials/
-```
-
-Example output:
-```
-abc1234 feat: add article card component
-def5678 feat: add navigation header
-ghi9012 feat: add hamburger menu
-jkl3456 feat: add breadcrumb navigation
-mno7890 docs: update week 3 completion report
-
- themes/danix-xyz-hacker/assets/css/main.css | +180 -0
- themes/danix-xyz-hacker/layouts/partials/card.html | +45 -0
- themes/danix-xyz-hacker/layouts/partials/nav.html | +32 -0
- WEEK3-IMPLEMENTATION.md | +200 -0
- 3 files changed, 457 insertions(+)
+# Check git log looks good
+git log --oneline -10
```
-### Step 6: Test Thoroughly
+### Step 5: Test Thoroughly Before Merge
-Before merging, test everything on the feature branch:
+Test everything on the feature branch:
```bash
# Start dev server
hugo server
# Test in browser:
-# - Dark mode (several pages)
-# - Light mode (toggle, verify all components)
-# - Mobile (320px)
-# - Tablet (768px)
-# - Desktop (1060px+)
-# - Keyboard navigation (Tab, Enter, Escape)
-# - All new components interactive
+# - Dark mode
+# - Light mode
+# - Mobile (320px), tablet (768px), desktop (1060px+)
+# - Keyboard navigation (Tab, Shift+Tab, Escape)
+# - All interactive elements
+# - Responsive layouts
# Run CSS build without errors
npm run build
git commit -m "docs: week 3 implementation complete"
```
-### Step 8: Merge Back to Master
+### Step 6: Merge to Master
-Once testing is complete and you're satisfied with all changes:
+Once testing is complete:
```bash
# Switch to master
git checkout master
+git pull origin master
-# Merge feature branch (creates merge commit)
-git merge week-3-cards-nav
-
-# Or merge with --squash if you want single commit per week
-# git merge --squash week-3-cards-nav
-# git commit -m "feat: week 3 - card layouts and navigation components"
+# Merge feature branch
+git merge feature/my-feature
-# Delete the feature branch (optional, good practice)
-git branch -d week-3-cards-nav
+# Optional: Delete the feature branch
+git branch -d feature/my-feature
# Verify merge
git log --oneline -10
+
+# Push to staging (no deploy yet)
+git push origin master
```
-After merge, master will have all Week 3 changes.
+### Step 7: Deploy to Production
-### Step 9: Prepare for Next Week
+When master is ready for the live site:
```bash
-# Create Week 4 branch from updated master
-git checkout -b week-4-forms-interactions
+# Switch to production
+git checkout production
+git pull origin production
+
+# Merge master into production
+git merge master
+
+# This triggers the post-receive hook and live deploy
+git push origin production
-# Continue with Week 4 work...
+# Verify deployment
+# - Check server logs
+# - Test the live site
```
---
