@wondev/dotenv-example 1.0.0

package/.claude/settings.local.json

@@ -0,0 +1,9 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(mkdir:*)",
+      "Bash(chmod:*)"
+    ],
+    "deny": []
+  }
+}

package/.cursor/README.md

@@ -0,0 +1,10 @@
+# .cursor
+
+## Supabase
+
+- https://supabase.com/docs/guides/getting-started/ai-prompts
+- https://supabase.com/ui/docs/ai-editors-rules/prompts
+
+## TaskMaster AI 
+
+- https://github.com/eyaltoledano/claude-task-master/tree/main/.cursor

package/.cursor/mcp.json

@@ -0,0 +1,31 @@
+{
+  "mcpServers": {
+    "sequential-thinking": {
+      "command": "bunx",
+      "args": ["@modelcontextprotocol/server-sequential-thinking"]
+    },
+    "context7": {
+      "command": "bunx",
+      "args": ["@upstash/context7-mcp"]
+    },
+    "playwright": {
+      "command": "bunx",
+      "args": ["@playwright/mcp@latest"]
+    },
+    "supabase": {
+      "command": "bunx",
+      "args": [
+        "@supabase/mcp-server-supabase@latest",
+        "--access-token",
+        "your_supabase_access_token"
+      ]
+    },
+    "notionApi": {
+      "command": "bunx",
+      "args": ["@notionhq/notion-mcp-server"],
+      "env": {
+        "OPENAPI_MCP_HEADERS": "{\"Authorization\": \"Bearer your_notion_access_token\", \"Notion-Version\": \"2022-06-28\" }"
+      }
+    }
+  }
+}

package/.cursor/rules/common/cursor-rules.mdc

@@ -0,0 +1,53 @@
+---
+description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
+globs: .cursor/rules/*.mdc
+alwaysApply: true
+---
+
+- **Required Rule Structure:**
+  ```markdown
+  ---
+  description: Clear, one-line description of what the rule enforces
+  globs: path/to/files/*.ext, other/path/**/*
+  alwaysApply: boolean
+  ---
+
+  - **Main Points in Bold**
+    - Sub-points with details
+    - Examples and explanations
+  ```
+
+- **File References:**
+  - Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files
+  - Example: [prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
+  - Example: [schema.prisma](mdc:prisma/schema.prisma) for code references
+
+- **Code Examples:**
+  - Use language-specific code blocks
+  ```typescript
+  // ✅ DO: Show good examples
+  const goodExample = true;
+  
+  // ❌ DON'T: Show anti-patterns
+  const badExample = false;
+  ```
+
+- **Rule Content Guidelines:**
+  - Start with high-level overview
+  - Include specific, actionable requirements
+  - Show examples of correct implementation
+  - Reference existing code when possible
+  - Keep rules DRY by referencing other rules
+
+- **Rule Maintenance:**
+  - Update rules when new patterns emerge
+  - Add examples from actual codebase
+  - Remove outdated patterns
+  - Cross-reference related rules
+
+- **Best Practices:**
+  - Use bullet points for clarity
+  - Keep descriptions concise
+  - Include both DO and DON'T examples
+  - Reference actual code over theoretical examples
+  - Use consistent formatting across rules 

package/.cursor/rules/common/git-convention.mdc

@@ -0,0 +1,86 @@
+---
+description: Git convention defining branch naming, commit message format, and issue labeling based on GitFlow and Conventional Commits.
+globs:
+alwaysApply: false
+---
+# Git Convention
+
+- 깃 브랜치 전략은 GitFlow를 따르며 이를 기반으로 한 브랜치 네이밍 컨벤션을 사용합니다.
+- 브랜치 네이밍 형식: `type/[branch/]description[-#issue]`
+  - [] 안의 내용은 선택 사항입니다.
+  - `type`: 브랜치 타입
+  - `branch`: 분기한 브랜치명 (e.g. `dev`, `main`)
+  - `description`: 브랜치 설명
+  - `issue`: 관련된 이슈 번호
+
+## Branch Type Description
+
+- **feat** (feature)
+  새로운 기능을 추가할 때 사용합니다.
+  예: `feat/login-#123`
+- **fix** (bug fix)
+  버그를 수정할 때 사용합니다.
+  예: `fix/button-click-#456`
+- **docs** (documentation)
+  문서 작업(README, 주석 등)을 할 때 사용합니다.
+  예: `docs/api-docs-#789`
+- **style** (formatting, missing semi colons, …)
+  코드 스타일(포맷 수정, 세미콜론 추가 등)을 수정할 때 사용합니다. 기능 수정은 포함되지 않습니다.
+  예: `style/css-format-#101`
+- **refactor**
+  코드 리팩토링(기능 변경 없이 코드 구조 개선)을 할 때 사용합니다.
+  예: `refactor/auth-service-#102`
+- **test** (when adding missing tests)
+  테스트 코드를 추가하거나 수정할 때 사용합니다.
+  예: `test/unit-tests-#103`
+- **chore** (maintain)
+  프로젝트 유지 보수 작업(빌드 설정, 패키지 업데이트 등)을 할 때 사용합니다.
+  예: `chore/dependency-update-#104`
+
+## Commit Message Convention
+
+`git config --local commit.template .github/.gitmessage` 명령어를 통해 커밋 메시지 템플릿을 설정할 수 있습니다.
+컨벤션 내용은 AngularJS Git Commit Message Conventions와 Conventional Commits을 기반으로 작성되어 있으며 `.github/.gitmessage` 파일에 작성되어 있습니다.
+
+```sh
+# commit message template
+#=================#
+# <type>(<scope>): <subject>
+# <BLANK LINE>
+# <body>
+# <BLANK LINE>
+# <footer>
+#=================#
+
+
+# Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on github as well as in various git tools.
+
+## Subject line
+# Subject line contains succinct description of the change.
+
+# Allowed `<type>`
+# feat (feature): 새로운 기능 추가
+# fix (bug fix): 버그 수정
+# docs (documentation): 문서 작업
+# style (formatting, missing semi colons, …): 코드 스타일 수정
+# refactor: 기능 변경 없이 코드 구조 개선
+# test (when adding missing tests): 테스트 코드 추가 또는 기존 테스트 수정
+# chore (maintain): 빌드, 패키지 매니저 설정 등 코드 수정이 없는 작업
+
+# Allowed `<scope>`
+# Scope could be anything specifying place of the commit change. For example $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc...
+
+# `<subject>` text
+# - use imperative, present tense: “change” not “changed” nor “changes”
+# - don't capitalize first letter
+# - no dot (.) at the end
+
+## Message body
+# - just as in <subject> use imperative, present tense: “change” not “changed” nor “changes”
+# - includes motivation for the change and contrasts with previous behavior
+...
+```
+
+## Issue Label Setting
+
+`github-label-sync --access-token <access_token> --labels .github/labels.json <owner>/<repo>`

package/.cursor/rules/common/self-improve.mdc

@@ -0,0 +1,72 @@
+---
+description: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
+globs: **/*
+alwaysApply: true
+---
+
+- **Rule Improvement Triggers:**
+  - New code patterns not covered by existing rules
+  - Repeated similar implementations across files
+  - Common error patterns that could be prevented
+  - New libraries or tools being used consistently
+  - Emerging best practices in the codebase
+
+- **Analysis Process:**
+  - Compare new code with existing rules
+  - Identify patterns that should be standardized
+  - Look for references to external documentation
+  - Check for consistent error handling patterns
+  - Monitor test patterns and coverage
+
+- **Rule Updates:**
+  - **Add New Rules When:**
+    - A new technology/pattern is used in 3+ files
+    - Common bugs could be prevented by a rule
+    - Code reviews repeatedly mention the same feedback
+    - New security or performance patterns emerge
+
+  - **Modify Existing Rules When:**
+    - Better examples exist in the codebase
+    - Additional edge cases are discovered
+    - Related rules have been updated
+    - Implementation details have changed
+
+- **Example Pattern Recognition:**
+  ```typescript
+  // If you see repeated patterns like:
+  const data = await prisma.user.findMany({
+    select: { id: true, email: true },
+    where: { status: 'ACTIVE' }
+  });
+  
+  // Consider adding to [prisma.mdc](mdc:.cursor/rules/prisma.mdc):
+  // - Standard select fields
+  // - Common where conditions
+  // - Performance optimization patterns
+  ```
+
+- **Rule Quality Checks:**
+  - Rules should be actionable and specific
+  - Examples should come from actual code
+  - References should be up to date
+  - Patterns should be consistently enforced
+
+- **Continuous Improvement:**
+  - Monitor code review comments
+  - Track common development questions
+  - Update rules after major refactors
+  - Add links to relevant documentation
+  - Cross-reference related rules
+
+- **Rule Deprecation:**
+  - Mark outdated patterns as deprecated
+  - Remove rules that no longer apply
+  - Update references to deprecated rules
+  - Document migration paths for old patterns
+
+- **Documentation Updates:**
+  - Keep examples synchronized with code
+  - Update references to external docs
+  - Maintain links between related rules
+  - Document breaking changes
+Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure.

package/.cursor/rules/common/tdd.mdc

@@ -0,0 +1,81 @@
+---
+description: Guidelines for writing tests and implementing code following TDD and Tidy First principles.
+alwaysApply: false
+---
+
+Always follow the instructions in plan.md. When I say "go", find the next unmarked test in plan.md, implement the test, then implement only enough code to make that test pass.
+
+# ROLE AND EXPERTISE
+
+You are a senior software engineer who follows Kent Beck's Test-Driven Development (TDD) and Tidy First principles. Your purpose is to guide development following these methodologies precisely.
+
+# CORE DEVELOPMENT PRINCIPLES
+
+- Always follow the TDD cycle: Red → Green → Refactor
+- Write the simplest failing test first
+- Implement the minimum code needed to make tests pass
+- Refactor only after tests are passing
+- Follow Beck's "Tidy First" approach by separating structural changes from behavioral changes
+- Maintain high code quality throughout development
+
+# TDD METHODOLOGY GUIDANCE
+
+- Start by writing a failing test that defines a small increment of functionality
+- Use meaningful test names that describe behavior (e.g., "shouldSumTwoPositiveNumbers")
+- Make test failures clear and informative
+- Write just enough code to make the test pass - no more
+- Once tests pass, consider if refactoring is needed
+- Repeat the cycle for new functionality
+
+# TIDY FIRST APPROACH
+
+- Separate all changes into two distinct types:
+  1. STRUCTURAL CHANGES: Rearranging code without changing behavior (renaming, extracting methods, moving code)
+  2. BEHAVIORAL CHANGES: Adding or modifying actual functionality
+- Never mix structural and behavioral changes in the same commit
+- Always make structural changes first when both are needed
+- Validate structural changes do not alter behavior by running tests before and after
+
+# COMMIT DISCIPLINE
+
+- Only commit when:
+  1. ALL tests are passing
+  2. ALL compiler/linter warnings have been resolved
+  3. The change represents a single logical unit of work
+  4. Commit messages clearly state whether the commit contains structural or behavioral changes
+- Use small, frequent commits rather than large, infrequent ones
+
+# CODE QUALITY STANDARDS
+
+- Eliminate duplication ruthlessly
+- Express intent clearly through naming and structure
+- Make dependencies explicit
+- Keep methods small and focused on a single responsibility
+- Minimize state and side effects
+- Use the simplest solution that could possibly work
+
+# REFACTORING GUIDELINES
+
+- Refactor only when tests are passing (in the "Green" phase)
+- Use established refactoring patterns with their proper names
+- Make one refactoring change at a time
+- Run tests after each refactoring step
+- Prioritize refactorings that remove duplication or improve clarity
+
+# EXAMPLE WORKFLOW
+
+When approaching a new feature:
+
+1. Write a simple failing test for a small part of the feature
+2. Implement the bare minimum to make it pass
+3. Run tests to confirm they pass (Green)
+4. Make any necessary structural changes (Tidy First), running tests after each change
+5. Commit structural changes separately
+6. Add another test for the next small increment of functionality
+7. Repeat until the feature is complete, committing behavioral changes separately from structural ones
+
+Follow this process precisely, always prioritizing clean, well-tested code over quick implementation.
+
+Always write one test at a time, make it run, then improve structure. Always run all the tests (except long-running tests) each time.
+
+<!-- https://www.stdy.blog/warning-signs-for-off-track-ai-and-tdd-system-prompts-by-kent-beck/ -->

package/.cursor/rules/common/vibe-coding.mdc

@@ -0,0 +1,114 @@
+---
+description: Core rules for AI-assisted Vibe Coding: Focus on TDD with mandatory external search for error resolution, robust context management (early file documentation, small modules, .cursor & README usage), incremental refactoring, and supportive user interaction, including automated quality fixes.
+globs:
+alwaysApply: true
+---
+# Rules for Vibe Coding
+
+## General Coding Guidance
+
+- 생성하는 모든 코드는 명확하고, 간결하며, 유지보수 가능해야 합니다.
+- 복잡한 로직은 단순화하고 불필요한 추상화는 피하십시오. 꼭 필요한 경우에만 도입하여 복잡성을 관리하십시오.
+- 모든 공개 API 및 복잡한 로직에는 명확한 주석(예: JSDoc, Python Docstrings)을 작성하십시오. 코드의 의도와 작동 방식을 설명해야 합니다.
+- 오류 처리는 항상 명시적으로 수행하며, 사용자에게 친화적인 오류 메시지를 제공하십시오. 단순한 try-catch 블록으로 오류를 숨기지 마십시오.
+- 보안을 최우선으로 고려하여 코드를 작성하십시오. 잠재적인 취약점(예: SQL 인젝션, XSS, API 키 노출)을 방지하기 위한 검증 및 이스케이프 처리를 철저히 하십시오.
+- 성능을 고려하여 효율적인 알고리즘과 데이터 구조를 선택하십시오. 불필요한 반복이나 계산을 피하십시오.
+
+## Test-Driven Development (TDD)
+
+- 기능 구현 요청 시, 먼저 해당 기능의 요구사항을 충족하는 포괄적인 단위 테스트 케이스를 작성하십시오. (필요시 통합 테스트 포함)
+- 테스트 케이스는 긍정적 케이스, 부정적 케이스, 엣지 케이스를 모두 포함해야 합니다.
+- 테스트 케이스 작성 후, 해당 테스트를 통과하는 최소한의 코드를 구현하십시오.
+- 코드 구현 후 모든 테스트를 실행하고, 실패하는 테스트가 있다면 해당 테스트를 통과하도록 코드를 수정하십시오. 이 과정을 모든 테스트가 통과할 때까지 반복하십시오. 각 수정 시도 전, 웹 검색 또는 공식 문서 (context7 mcp 활용 등) 조사를 필수로 수행해야 합니다.
+- 최대 3회를 초과하여 동일한 오류 수정 루프에 빠지지 않도록 주의하고, 해결이 어려울 경우 사용자에게 도움을 요청하십시오.
+- 사용자로부터 테스트 실패 로그가 제공되면, 해당 로그를 분석하여 문제의 원인을 파악하고 코드를 수정하십시오.
+- 생성된 테스트 코드는 사람이 쉽게 이해하고 유지보수할 수 있도록 명확하게 작성하십시오.
+
+## Feature Implementation Workflow
+
+기능을 구현할 때는 **반드시** 다음의 조건과 단계를 따릅니다:
+1.  **계획 수립 및 검토:**
+   - 요구사항 분석을 바탕으로 구체적인 구현 계획을 세웁니다.
+   - 수립된 계획을 사용자에게 제시하고, 진행 전에 반드시 검토와 승인을 받습니다.
+2.  **단계적 구현 및 검증:**
+   - 기능 구현 과정을 논리적인 작은 단위로 세분화하여 단계적으로 진행합니다.
+   - 각 단계의 핵심 로직에는 서버 및 클라이언트 환경 모두에 로그(예: `console.group`, `console.log`)를 추가합니다.
+       - 로그는 기능의 정상 작동 여부를 확인하고, 잠재적인 문제를 조기에 발견하여 디버깅하는 데 활용됩니다.
+       - 구현이 완료되고 안정화된 후에는 디버깅 목적의 로그는 제거하거나, 필요한 경우 최소한으로 유지하는 것을 고려합니다.
+   - 각 단계 구현 후에는 충분한 테스트와 검증을 통해 의도한 대로 작동하는지 확인합니다.
+
+## Context Management
+
+- 각 코드 파일의 첫 100줄 이내에 해당 파일의 기능, 구현 로직, 주요 의존성을 명확히 문서화하세요. 이는 AI가 파일을 빠르고 정확하게 이해하는 데 도움을 줍니다. 아래 예시 형식을 따르십시오:
+
+  ```tsx
+  /**
+   * @file UserProfile.tsx
+   * @description 사용자 프로필 페이지 컴포넌트
+   *
+   * 이 컴포넌트는 사용자의 프로필 정보를 표시하고 수정하는 기능을 제공합니다.
+   *
+   * 주요 기능:
+   * 1. 사용자 기본 정보 표시 (이름, 이메일, 프로필 이미지)
+   * 2. 프로필 정보 수정
+   * 3. 프로필 이미지 업로드
+   *
+   * 핵심 구현 로직:
+   * - Supabase Auth를 통한 사용자 인증 상태 확인
+   * - React Query를 사용한 프로필 데이터 fetching 및 Caching
+   * - 이미지 업로드를 위한 Supabase Storage 활용 (클라이언트 측 직접 업로드)
+   * - Form 상태 관리를 위한 React Hook Form 사용 (유효성 검사 포함)
+   *
+   * @dependencies
+   * - @supabase/ssr: 인증 및 서버 사이드 Supabase 클라이언트
+   * - @tanstack/react-query: 데이터 동기화 및 캐싱
+   * - react-hook-form: 폼 관리 및 유효성 검사
+   * - @heroicons/react: UI 아이콘
+   *
+   * @see {@link /docs/user-profile-design.md} - 관련 디자인 문서
+   * @see {@link /docs/api/users.md#PUT /api/users/:id} - 프로필 업데이트 API 명세
+   */
+
+  import { useEffect } from "react";
+  import { useForm } from "react-hook-form";
+  import { useQuery, useMutation, useQueryClient } from "@tanstack/react-query"; // QueryClient 추가
+  import { createClient } from "@/utils/supabase/client";
+  import { UserCircleIcon } from "@heroicons/react/24/outline";
+
+  // ... 컴포넌트 구현 ...
+  ```
+
+- 기능은 논리적으로 분리된 작은 모듈 또는 패키지로 구성하십시오. 단일 파일이 500 라인을 넘지 않도록 노력하고, 필요시 파일을 분리하는 것을 적극적으로 제안하십시오.
+- 새로운 기능을 구현할 때, 기존 프로젝트의 디렉토리 구조와 네이밍 컨벤션을 철저히 준수하십시오.
+- 파일 및 디렉토리 이름은 해당 내용물의 기능을 명확하게 나타내도록 작성하십시오. (예: `user-auth-service.ts`, `product-display-component.tsx`)
+- 전체 컨텍스트가 주어질 경우, 주요 파일 및 사용자 지침에 따라 필요한 정보를 요약 및 활용하되, 중요한 세부사항(특히 사용자가 명시한 제약 조건이나 우선순위)을 놓치지 않도록 주의하십시오.
+- 프로젝트 루트의 `.cursor` 폴더에 위치한 디자인 문서, 작업 체크리스트(`todo.md`), 제품 요구사항 문서(`prd.md`), 추가 규칙 파일들을 항상 최우선으로 참조하여 작업의 일관성과 정확성을 유지하십시오.
+- 프로젝트의 상태와 구조, 주요 결정 사항을 `README.md`와 같은 중앙 문서에 정기적으로 문서화하도록 사용자에게 상기시키거나, 직접 초안을 작성하여 제안하십시오.
+
+## Refactoring (리팩토링)
+
+- 리팩토링은 점진적으로, 작은 단위로 수행하십시오. 대규모의 전면적인 변경은 사용자에게 항상 확인받고 진행하십시오.
+- 기존 코드의 스타일과 패러다임을 일관되게 유지하십시오. 새로운 라이브러리나 스타일을 도입해야 할 경우, 반드시 사용자에게 명시적인 확인과 승인을 요청하십시오.
+- 불필요한 추상화 계층을 만들지 마십시오. 코드는 가능한 단순하게 유지하되, 명확성을 희생해서는 안 됩니다. 모든 추상화는 그 필요성을 명확히 설명할 수 있어야 합니다.
+- 리팩토링 전후로 반드시 테스트를 실행하여 기존 기능이 손상되지 않았는지 확인하십시오. 필요한 경우, 리팩토링 범위에 맞춰 테스트 케이스를 업데이트하거나 추가 작성하십시오.
+- 사용자로부터 '잘못된 리팩토링 함정'(예: 비즈니스 컨텍스트 미이해, 과도한 통합, 성능 저하 유발)에 대한 지적을 받으면, 해당 피드백을 최우선으로 반영하여 수정하고, 수정 내용을 사용자에게 명확히 설명하십시오.
+
+## User Instructions (사용자 지침 준수)
+
+- 사용자의 요청이 모호하거나 불완전하다고 판단되면, 주저하지 말고 명확화를 위한 구체적인 질문을 하십시오. 추측에 기반하여 코드를 생성하지 마십시오.
+- 사용자가 '아이디어 구체화' 또는 '계획 수립' 단계를 요청하면, 체계적인 질문(예: 목표, 주요 기능, 사용자, 기술 제약)을 통해 상세한 명세(`.cursor/prd.md`) 또는 실행 가능한 작업 목록(`.cursor/todo.md`)을 도출하도록 적극적으로 지원하십시오.
+- 사용자가 '일회용 코드' 또는 '학습 목적의 코드'를 요청할 경우, 유지보수성보다는 기능 구현 및 개념 설명에 더 중점을 둘 수 있습니다. 단, 이 경우에도 기본적인 코드 품질(가독성, 보안 기초)은 유지하고, 해당 코드의 한계를 사용자에게 명확히 고지하십시오.
+- 사용자가 제공하는 `prd.md`, `todo.md`, `README.md` 등의 문서는 작업의 핵심적인 가이드라인이므로 반드시 숙지하고 철저히 따르십시오. 내용이 상충되거나 불분명한 경우 즉시 사용자에게 확인 요청하십시오.
+
+## Automation (자동화)
+
+- 품질 검사 도구(린터, 정적 분석기 등)에서 오류나 경고가 발생하면, 해당 내용을 분석하여 코드를 자동으로 수정하십시오. 이 과정에서 오류/경고가 없을 때까지 반복할 수 있으나, 각 수정 시도 전, 해당 오류/경고에 대한 웹 검색 또는 공식 문서(context7 mcp 활용 ) 조사를 필수로 수행하여 최적의 해결책을 적용해야 합니다.
+- 최대 3회를 초과하여 동일한 오류 수정 루프에 빠지지 않도록 주의하고, 해결이 어려울 경우 사용자에게 현재까지의 시도와 문제점을 요약하여 보고하고 도움을 요청하십시오.
+
+## Supporting (사용자 지원)
+
+- 사용자가 기술 용어나 개발 프로세스에 익숙하지 않을 수 있음을 인지하고, 가능한 쉬운 용어로 설명하거나, 필요한 경우 비유나 구체적인 예시를 들어 추가적인 설명을 제공하십시오.
+- 사용자가 문제 정의(PRD, 와이어프레임)를 명확히 하도록 돕고, 이를 기반으로 신속하게 프로토타입을 생성하여 시각적인 피드백 루프를 형성하고 사용자의 아이디어를 구체화하는 데 기여하십시오.
+- 사용자가 'AI가 코드를 잘 작성하도록 프롬프팅'하는 방법을 문의하면, 명확한 역할 부여, 충분한 컨텍스트 제공, 구체적인 작업 지시의 중요성을 설명하고, 효과적인 프롬프트 패턴 예시를 제공하십시오.
+- 사용자가 '내가 더 똑똑해지기'를 원할 경우, 관련 기술 키워드, 데이터 흐름, 실행 환경, 아키텍처 패턴 등에 대한 학습 자료(요약, 링크 등)를 제공하거나 관련 질문에 상세히 답변하여 사용자의 이해를 돕고 성장을 지원하십시오.
+- 사용자가 '기능이 스펙대로 동작한다'는 목표를 달성하도록, 테스트 코드 작성의 중요성과 방법, 테스트 실행 및 결과 해석 과정을 명확히 안내하고, 버전 관리 시스템(예: Git)을 통한 커밋(저장)의 중요성과 기본 워크플로우를 설명하십시오.