깃 & 전달 핵심 B · 공식 안내 플랫폼: 일반

Git Merge

Git 병합

Git 병합은 브랜치 히스토리를 합칩니다. Git은 포인터를 앞으로 이동시키거나 충돌 해결 후 병합 커밋을 생성할 수 있습니다.

당신은 이것을 이렇게 부를 수 있습니다 Git Merge병합 커밋빨리 감기 병합브랜치 통합

작동 방식을 확인하세요

원본 작업 예제Git 병합

다른 예시

feature 브랜치가 main에서 떨어져 나왔어요. 작성자가 테스트를 고치고, 담당자와 충돌을 하나 해결한 다음, CI를 통과하면 merge해요.

주요 부분

  1. 01Branch or change set
  2. 02Review and verification gate
  3. 03Released result

사용할 때

이것은 검토된 작업을 통합하면서 저장소 규칙을 따르는 데 사용하세요.

다음 경우에는 사용하지 마세요

한쪽 충돌 측만 맹목적으로 선택하지 마세요, 실패한 작업을 병합하지 마세요, 합의 없이 공유 히스토리를 다시 작성하지 마세요.

코드에서 사용된 이름

git merge <branch>

출시하기 전에

Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback.

복사 가능한 요청

Outcome:Complete the task with Git 병합 (Git Merge)。 User context:feature 브랜치가 main에서 떨어져 나왔어요. 작성자가 테스트를 고치고, 담당자와 충돌을 하나 해결한 다음, CI를 통과하면 merge해요. Delivery concept or operation:Git 병합 (Git Merge)。 Why it fits:이것은 검토된 작업을 통합하면서 저장소 규칙을 따르는 데 사용하세요. Do not use it when:한쪽 충돌 측만 맹목적으로 선택하지 마세요, 실패한 작업을 병합하지 마세요, 합의 없이 공유 히스토리를 다시 작성하지 마세요. Delivery requirements: Name the code repository and target. List preconditions, changes, review and CI checks, conflict and data-loss risks, release order, and the rollback or recovery command. Repository safeguards: Keep unpublished work and a clear history. Do not run destructive steps without an explicit backup. Check the exact code diff and remote target before publishing. Acceptance criteria: Review the intended diff and pass all required checks. Keep the target version traceable. Practice failure recovery and keep published history clear. Evidence and limits (evidence boundary):해당 출처에 대해 공식적인 것입니다. 다른 플랫폼이나 팀은 그 용어를 다른 방식으로 사용할 수 있습니다. Unknowns to confirm: Repository, branch, team activity, release environment, approval owner, protected checks, and rollback target.

이 요청을 확인하세요

Review how Git 병합 (Git Merge) is used now. Definition: Git 병합은 브랜치 히스토리를 합칩니다. Git은 포인터를 앞으로 이동시키거나 충돌 해결 후 병합 커밋을 생성할 수 있습니다. Release checks: Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.

B
이 용어는 얼마나 공식적인가요?

공식 안내

명명된 플랫폼, 프레임워크, 프로젝트 또는 전문가 그룹에는 이 용어에 대한 공식 가이드가 있습니다.

해당 출처에 대해 공식적인 것입니다. 다른 플랫폼이나 팀은 그 용어를 다른 방식으로 사용할 수 있습니다.

범위
소스가 포함하는 것만:정규 이름、정의、플랫폼 API、구현、사용 안내
문서 상태
안정적인
선택됨
2026-07-30

증거 출처 및 범위

권위 있는 출처 · Git · 안정적인 git-merge 범위: 정규 이름、정의、플랫폼 API、구현、사용 안내 여기 역할: 명시된 범위 안의 권위 출처 범위: 정규 이름, 정의, 플랫폼 API, 구현, 사용 안내

직접 복사

브라우저가 이것을 복사할 수 없습니다. 아래 요청을 선택하고 직접 복사하세요.