From: Danilo M. Date: Tue, 28 Apr 2026 08:38:08 +0000 (+0200) Subject: docs: update git workflow for production branch strategy X-Git-Tag: release_28042026-1041~1 X-Git-Url: https://git.danix.xyz/?a=commitdiff_plain;h=ba462ddcef07445294d4e19ca0c5d440d8c51b12;p=danix.xyz-2.git docs: update git workflow for production branch strategy Replace master-as-deploy with three-branch model: feature branches → master (staging) → production (live). Master no longer triggers deploy. Updated CLAUDE.md, AGENTS.md, WORKFLOW.md, and all docs/policies files to reflect production branch approach. Includes deployment commands and updated FAQ. Co-Authored-By: Claude Haiku 4.5 --- diff --git a/AGENTS.md b/AGENTS.md index c3b03b5..b77ab1a 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -5,6 +5,9 @@ You are the content curator for https://danix.xyz. You manage bilingual (IT/EN) ## 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/ diff --git a/CLAUDE.md b/CLAUDE.md index 3afcf7c..184537d 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -42,6 +42,11 @@ DO NOT write code for shortcodes without consulting the user first. Implement: - 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` @@ -52,9 +57,10 @@ DO NOT write code for shortcodes without consulting the user first. Implement: 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` diff --git a/WORKFLOW.md b/WORKFLOW.md index f8e6fee..6743d9d 100644 --- a/WORKFLOW.md +++ b/WORKFLOW.md @@ -12,9 +12,19 @@ That directory is a full clone of `danix2-hugo-theme` — you can push from ther --- +## 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 @@ -24,7 +34,7 @@ hugo new content/en/articles/my-new-article/index.md # 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 @@ -138,20 +148,26 @@ git push origin master ## 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). --- @@ -232,17 +248,23 @@ ssh danix_git "git -C ~/repositories/danix2-hugo-theme.git log --oneline | head ## Quick Reference ``` -# content change → deploy +# content change → staging (master) cd ~/Programming/GIT/danix.xyz-hacker-theme git add && 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 && 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 diff --git a/docs/policies/BRANCHING-POLICY.md b/docs/policies/BRANCHING-POLICY.md index ddc5138..4fd9ce3 100644 --- a/docs/policies/BRANCHING-POLICY.md +++ b/docs/policies/BRANCHING-POLICY.md @@ -1,110 +1,137 @@ -# 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--` -**Example:** `week-3-cards-nav`, `week-4-forms-interactions` +**Format for feature branches:** `week--`, `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 @@ -112,72 +139,73 @@ git diff --stat master..week-3-cards-nav # 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--` (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 @@ -196,33 +224,49 @@ docs: week 3 implementation complete - [ ] 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 +``` --- diff --git a/docs/policies/GIT-WORKFLOW-QUICK-REF.md b/docs/policies/GIT-WORKFLOW-QUICK-REF.md index 43c6a6d..c79d62b 100644 --- a/docs/policies/GIT-WORKFLOW-QUICK-REF.md +++ b/docs/policies/GIT-WORKFLOW-QUICK-REF.md @@ -1,16 +1,22 @@ # 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 @@ -19,99 +25,87 @@ git 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 +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. diff --git a/docs/policies/GIT-WORKFLOW.md b/docs/policies/GIT-WORKFLOW.md index b421f83..ed07de8 100644 --- a/docs/policies/GIT-WORKFLOW.md +++ b/docs/policies/GIT-WORKFLOW.md @@ -1,68 +1,64 @@ -# 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-- +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 @@ -72,7 +68,7 @@ hugo server # Check what changed git status -git diff themes/danix-xyz-hacker/assets/css/main.css +git diff ``` ### Step 3: Commit Regularly @@ -97,81 +93,39 @@ git commit -m "feat: add article card component - 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 @@ -208,37 +162,46 @@ git add WEEK3-IMPLEMENTATION.md memory/week3_complete.md 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 ``` ---