# 버전 관리 연동 (/ko/docs/verdent-for-vscode/common-workflows/version-control)

> Git 및 기타 버전 관리 시스템과 작업하기



Verdent for VS Code는 Git 및 기타 버전 관리 시스템과 매끄럽게 연동되어 자연어 기반 버전 관리 작업, 자동 커밋 메시지 생성, 지능적인 브랜치 관리를 지원합니다. 이 가이드는 효율적인 버전 관리 워크플로를 위해 Verdent의 Git 연동을 활용하는 방법을 보여줍니다.

***

## 의미 있는 커밋 메시지 만들기 [#의미-있는-커밋-메시지-만들기]

변경 사항을 만들었고, Verdent가 설명적인 커밋 메시지를 생성하게 하고 싶다고 가정해 보겠습니다.

<Steps>
  <Step title="생성된 메시지로 커밋 요청하기">
    ```
    Stage all changes and create a commit with an appropriate message
    ```

    Verdent는 git diff를 사용해 변경 사항을 분석합니다.
  </Step>

  <Step title="Verdent가 변경 사항 분석하기">
    Verdent는 다음을 살펴봅니다.

    * 수정된 파일과 그 목적
    * 변경의 성격(새 기능, 버그 수정, 리팩터링)
    * 영향 범위
    * 관련 기능
  </Step>

  <Step title="설명적인 커밋 메시지 생성하기">
    ```bash
    git commit -m "feat: add user profile image upload with S3 integration

    - Add file upload endpoint to user API
    - Integrate AWS S3 for image storage
    - Update user model with profileImage field
    - Add frontend image upload component with preview"
    ```

    메시지는 conventional commit 형식을 따르며 무엇이 변경되었는지 설명합니다.
  </Step>

  <Step title="커밋 생성 완료">
    변경 사항이 생성된 메시지로 커밋됩니다. 커밋은 다음처럼 검토할 수 있습니다.

    ```bash
    git log -1
    ```
  </Step>
</Steps>

<Tip>
  **팁:**

  * Verdent는 conventional commit 형식(feat, fix, refactor, docs 등)을 따릅니다.
  * 커밋 메시지는 "어떻게"보다 "무엇"과 "왜"에 집중합니다.
  * User Rules 또는 Project Rules에서 커밋 메시지 형식을 사용자 지정할 수 있습니다.
  * 특정 커밋 메시지 스타일을 요청할 수 있습니다. "상세한 여러 줄 메시지로 커밋을 만들어줘"
</Tip>

***

## 커밋 메시지 형식 사용자 지정하기 [#커밋-메시지-형식-사용자-지정하기]

Verdent가 팀의 특정 커밋 메시지 규칙을 따르게 하고 싶다고 가정해 보겠습니다.

<Tabs>
  <Tab title="User Rules(전역)">
    모든 프로젝트에 적용할 커밋 메시지 선호 사항을 `VERDENT.md`에 정의합니다.

    ```markdown
    # VERDENT.md

    ## Git Commit Messages

    When generating commit messages:
    - Always include ticket number in format: [PROJ-123]
    - Use present tense verbs
    - Maximum 50 characters for first line
    - Include detailed explanation in body
    - Add "Co-authored-by" for pair programming sessions

    Example format:
    [PROJ-123] Add user authentication feature

    Detailed explanation of changes...

    Co-authored-by: Team Member <email@example.com>
    ```

    Verdent는 이 규칙을 전역으로 따릅니다.
  </Tab>

  <Tab title="Project Rules">
    프로젝트별 커밋 규칙을 `AGENTS.md`에 정의합니다.

    ```markdown
    # AGENTS.md

    ## Git Commit Conventions

    For this project, use conventional commits with these scopes:
    - feat(api): API changes
    - feat(ui): Frontend changes
    - fix(auth): Authentication fixes
    - docs(readme): Documentation updates

    Always reference GitHub issue: "Fixes #123" or "Relates to #456"
    ```

    규칙은 이 프로젝트에만 적용됩니다.
  </Tab>

  <Tab title="인라인 지시">
    일회성 지시를 직접 제공합니다.

    ```
    Create a commit with message format: "[TICKET-NUMBER] description" including reference to issue #42
    ```

    Verdent는 다음을 생성합니다.

    ```bash
    git commit -m "[PROJ-42] Add search functionality

    Relates to #42"
    ```
  </Tab>
</Tabs>

<Tip>
  **팁:**

  * User Rules는 모든 프로젝트에 전역으로 적용됩니다.
  * Project Rules(AGENTS.md)는 특정 프로젝트에서 User Rules보다 우선합니다.
  * 인라인 지시는 일회성 요구 사항에 대해 둘 다보다 우선합니다.
  * 일관성을 위해 Conventional Commits 형식을 권장합니다.
</Tip>

***

## Pull Request 만들기 [#pull-request-만들기]

Verdent가 포괄적인 pull request를 만들게 하고 싶다고 가정해 보겠습니다.

<Steps>
  <Step title="변경 사항이 커밋되었는지 확인하기">
    ```
    Make sure all my changes are committed
    ```

    Verdent는 git status를 확인하고 커밋되지 않은 변경 사항이 있으면 커밋합니다.
  </Step>

  <Step title="브랜치를 원격에 푸시하기">
    ```
    Push this branch to origin
    ```

    Verdent는 다음을 푸시합니다.

    ```bash
    git push origin feature/user-notifications
    ```
  </Step>

  <Step title="PR 생성 요청하기">
    ```
    Create a pull request for this feature
    ```

    Verdent는 `gh` CLI를 사용해 PR을 만듭니다.
  </Step>

  <Step title="Verdent가 PR 설명 생성하기">
    Verdent는 커밋과 변경 사항을 분석해 다음을 생성합니다.

    **제목:** 사용자 알림 시스템 추가

    **본문:**

    ```markdown
    ## Summary
    - Implements real-time user notifications
    - Adds WebSocket support for instant delivery
    - Includes email fallback for offline users
    - Comprehensive test coverage

    ## Test Plan
    - [ ] Test real-time notifications in browser
    - [ ] Verify email fallback for offline users
    - [ ] Check notification persistence across sessions
    - [ ] Test with multiple concurrent users

    ## Changes
    - Added NotificationService with WebSocket integration
    - Created notification UI components
    - Integrated SendGrid for email notifications
    - Added notification preferences to user settings
    ```

    포괄적인 설명과 함께 PR이 생성됩니다.
  </Step>
</Steps>

<Tip>
  **팁:**

  * Verdent는 브랜치의 모든 커밋을 분석해 PR 설명을 생성합니다.
  * 특정 PR 형식을 요청할 수 있습니다. "상세한 테스트 플랜이 포함된 PR을 만들어줘"
  * 스크린샷을 포함할 수 있습니다. "이 스크린샷을 PR 설명에 추가해줘"
  * 생성 전에 PR 설명을 다듬을 수 있습니다. "breaking change를 언급하도록 PR을 업데이트해줘"
</Tip>

***

## Merge conflict 해결하기 [#merge-conflict-해결하기]

Merge conflict가 발생했고 Verdent의 도움이 필요하다고 가정해 보겠습니다.

<Steps>
  <Step title="merge 시도하기">
    ```
    Merge main into this feature branch
    ```

    Merge conflict가 발생합니다.

    ```bash
    Auto-merging src/auth.ts
    CONFLICT (content): Merge conflict in src/auth.ts
    ```
  </Step>

  <Step title="conflict 해결 요청하기">
    ```
    Help me resolve the merge conflict in src/auth.ts
    ```

    Verdent는 conflict marker를 읽습니다.
  </Step>

  <Step title="Verdent가 두 버전 분석하기">
    Verdent는 다음을 살펴봅니다.

    * 현재 브랜치 변경 사항(HEAD)
    * 들어오는 변경 사항(main 브랜치)
    * conflict 주변 컨텍스트
    * 두 변경 사항의 의도
  </Step>

  <Step title="Verdent가 해결안 제안하기">
    ```
    The conflict is between your JWT implementation and the main branch's session-based auth. I'll merge both approaches to support both authentication methods.
    ```

    Verdent는 두 변경 사항을 지능적으로 통합해 conflict를 해결합니다.
  </Step>

  <Step title="conflict를 해결됨으로 표시하기">
    ```bash
    git add src/auth.ts
    git commit -m "Merge main into feature/jwt-auth, resolved conflicts"
    ```

    conflict가 해결되고 merge가 완료됩니다.
  </Step>
</Steps>

<Tip>
  **팁:**

  * Verdent는 코드 컨텍스트를 이해해 conflict를 지능적으로 해결합니다.
  * 커밋하기 전에 항상 conflict 해결 내용을 검토하세요.
  * 복잡한 conflict의 경우, 먼저 Verdent에게 두 버전을 설명해 달라고 요청하세요.
  * conflict를 해결한 뒤에는 충분히 테스트하세요.
</Tip>

<Tip>
  Verdent는 양쪽 브랜치의 의도를 이해해 merge conflict를 분석하고, 양쪽 기능을 모두 보존하는 해결안을 제안합니다.
</Tip>

***

## 브랜치와 태그 관리하기 [#브랜치와-태그-관리하기]

브랜치를 관리하고 릴리스 태그를 만들어야 한다고 가정해 보겠습니다.

<Tabs>
  <Tab title="브랜치 작업">
    **브랜치 만들고 전환하기:**

    ```
    Create a new branch called feature/user-notifications
    ```

    Verdent는 다음을 실행합니다.

    <CodeGroup>
      ```bash "Create New Branch"
      git checkout -b feature/user-notifications
      ```

      ```bash "Switch to Existing Branch"
      git checkout main
      ```

      ```bash "Create and Push Branch"
      git checkout -b feature/payment-integration
      git push -u origin feature/payment-integration
      ```
    </CodeGroup>
  </Tab>

  <Tab title="merge">
    **기능 브랜치 merge하기:**

    ```
    Merge the feature/user-notifications branch into main
    ```

    Verdent는 merge 워크플로를 수행합니다.

    ```bash
    git checkout main
    git pull origin main
    git merge feature/user-notifications
    git push origin main
    ```

    Verdent는 merge 전에 main이 최신 상태인지 확인합니다.
  </Tab>

  <Tab title="릴리스 태그 지정">
    **annotated tag 만들기:**

    ```
    Create an annotated tag for version 1.2.0 with release notes
    ```

    Verdent는 상세한 태그를 만듭니다.

    ```bash
    git tag -a v1.2.0 -m "Release 1.2.0

    New Features:
    - User notification system
    - Email integration
    - Real-time WebSocket support

    Bug Fixes:
    - Fixed authentication timeout issue
    - Resolved cart calculation bug"
    ```

    **태그 푸시하기:**

    ```
    Push all tags to origin
    ```

    Verdent는 다음을 푸시합니다.

    ```bash
    git push origin --tags
    ```
  </Tab>
</Tabs>

<Tip>
  **팁:**

  * 설명적인 브랜치 이름을 사용하세요. `feature/user-auth`, `fix/cart-bug`, `refactor/api-layer`
  * merge하기 전에 항상 최신 변경 사항을 pull하세요.
  * 릴리스에는 annotated tag를 사용하세요. 메타데이터가 포함됩니다.
  * 시맨틱 버저닝을 따르세요. v1.2.3(major.minor.patch)
</Tip>

<Tip>
  일관된 브랜치 이름 규칙은 Verdent가 워크플로를 이해하는 데 도움이 됩니다. 자동으로 준수되도록 AGENTS.md에 패턴을 정의하세요.
</Tip>

***

## 자주 묻는 질문 [#자주-묻는-질문]

<Accordion title="Verdent가 변경 사항을 자동으로 커밋하나요?">
  아니요. Verdent는 명시적으로 요청한 경우에만 커밋을 만듭니다. 변경 사항을 언제 커밋할지는 사용자가 완전히 제어합니다. 준비되면 "모든 변경 사항을 stage하고 커밋을 만들어줘"라고 요청하면 됩니다.
</Accordion>

<Accordion title="커밋하기 전에 커밋 메시지를 수정할 수 있나요?">
  예. 커밋이 생성되기 전에 Verdent에게 커밋 메시지를 수정해 달라고 요청할 수 있습니다. "breaking change를 언급하도록 커밋 메시지를 업데이트해줘" 또는 "그 커밋 메시지를 더 간결하게 만들어줘"라고 말하세요. Verdent는 피드백을 바탕으로 메시지를 다시 생성합니다.
</Accordion>

<Accordion title="Verdent는 GitHub, GitLab, Bitbucket 및 기타 Git 플랫폼과 함께 작동하나요?">
  예. Verdent는 표준 Git 명령을 사용하므로 호스팅 플랫폼과 관계없이 모든 Git repository에서 작동합니다. Pull request를 만들 때는 Verdent가 GitHub가 필요한 `gh` CLI를 사용하지만, 그 외 모든 Git 작업은 어디서나 작동합니다.
</Accordion>

<Accordion title="Verdent가 묻지 않고 원격 repository에 푸시하나요?">
  아니요. Verdent는 명시적으로 요청한 경우에만 원격 repository에 푸시합니다. 안전을 위해 모든 Git 작업(commit, push, merge, rebase)은 사용자의 명시적인 지시가 필요합니다.
</Accordion>

<Accordion title="Verdent가 모든 유형의 merge conflict를 해결할 수 있나요?">
  Verdent는 코드 컨텍스트와 의도를 이해해 대부분의 텍스트 기반 merge conflict를 해결할 수 있습니다. 바이너리 파일 conflict나 매우 복잡한 다중 conflict는 수동 개입이 필요할 수 있습니다. 커밋하기 전에 항상 Verdent의 conflict 해결 내용을 검토하세요.
</Accordion>

***

## 함께 보기 [#함께-보기]

<CardGroup cols="2">
  <Card title="여러 단계 작업 예시" icon="list-check" href="/docs/verdent-for-vscode/common-workflows/multi-step-tasks">
    복잡한 여러 단계 워크플로와 작업 관리
  </Card>

  <Card title="새 코드 작성하기" icon="code" href="/docs/verdent-for-vscode/task-based-guides/writing-code">
    Verdent로 새 기능과 컴포넌트 만들기
  </Card>
</CardGroup>