@wondev/dotenv-example 1.0.1 → 1.0.3

package/.claude/settings.local.json

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

package/.cursor/README.md

@@ -1,10 +0,0 @@
-# .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

@@ -1,31 +0,0 @@
-{
-  "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

@@ -1,53 +0,0 @@
----
-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

@@ -1,86 +0,0 @@
----
-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

@@ -1,72 +0,0 @@
----
-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

@@ -1,81 +0,0 @@
----
-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

@@ -1,114 +0,0 @@
----
-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)을 통한 커밋(저장)의 중요성과 기본 워크플로우를 설명하십시오.