VIBECODING 365 / DICTIONARY
머지
Merge
DEFINITION
머지(merge)는 Git이 갈라진 개발 이력을 현재 브랜치로 다시 합치는 작업이다. 공식 문서 git-merge의 정의는 둘 이상의 개발 이력을 하나로 잇는다는 것이다. 기능 브랜치에서 쌓은 커밋을 메인에 넣는 일이 대표적이고, 원격 저장소의 새 커밋을 가져오는 git pull도 내부에서 같은 명령을 쓴다. 화면의 풀 리퀘스트 버튼도 결국 이 이력을 공유 브랜치에 반영하는 일이다.
브랜치가 갈라졌다는 뜻
한 저장소에서 메인을 기준으로 이슈용 브랜치를 따면, 그 순간부터 두 줄의 커밋이 따로 자란다. Pro Git의 기초 장은 이슈 브랜치에서 화면을 고치는 동안 프로덕션에 긴급 수정을 넣는 흐름으로 이 갈라짐을 설명한다. 긴급 수정이 먼저 메인에 들어가면, 나중에 이슈 브랜치를 넣을 때 두 줄은 이미 다른 지점에서 자라 있다. 머지는 그 두 줄을 한 스냅샷으로 맞추는 일이다. 합치려는 커밋이 이미 현재 브랜치의 조상이면 Git은 이미 최신이라고 보고 새 커밋을 만들지 않는다.
포인터만 옮기는 경우와 머지 커밋
메인이 상대 브랜치의 조상이면 Git은 새 커밋 없이 브랜치 포인터만 앞으로 민다. 이것을 패스트포워드라고 한다. Pro Git은 핫픽스 브랜치를 메인에 넣을 때 이 경우가 나온다고 적는다. 반대로 양쪽이 서로 커밋을 쌓은 뒤에는 세 스냅샷으로 내용을 맞추고 부모가 둘인 머지 커밋을 만든다. 세 장은 현재 브랜치 끝, 합치려는 브랜치 끝, 둘이 갈라지기 전 공통 조상이다. 한 쪽만 손본 구간은 그대로 들어가고, 같은 자리를 양쪽이 다르게 고친 구간만 사람에게 남는다. 한 브랜치를 합칠 때 Git의 기본 전략 이름은 ort이며, 이 세 갈래 비교와 이름 변경 감지를 한다. 깃허브의 기본 풀 리퀘스트 머지는 패스트포워드가 가능해도 머지 커밋을 남기도록 no-ff 옵션에 해당한다.
같은 자리를 양쪽이 고친 경우
같은 파일의 같은 구간을 양쪽이 다르게 바꾸면 Git은 자동으로 맞추지 못한다. 겹치지 않는 변경은 그대로 들어가므로, 충돌은 파일 전체가 실패한 뜻이 아니라 그 구간을 양쪽이 동시에 고쳤다는 뜻이다. 새 머지 커밋은 생기지 않고 과정이 멈춘다. 파일에는 내 쪽과 상대 쪽을 나누는 충돌 표시가 남고, 기본 표시는 갈라지기 전 원문을 보여 주지 않는다. 원문까지 보려면 충돌 표시 스타일을 diff3로 바꾸는 설정이 있다. Pro Git은 위쪽을 현재 브랜치, 아래쪽을 합치려던 브랜치로 읽고, 한쪽을 고르거나 내용을 새로 쓴 뒤 표시 줄을 모두 지우라고 한다. 파일을 인덱스에 올린 다음 커밋하거나 머지를 이어 가기로 마무리하고, 처음부터 다시 하려면 머지 중단으로 되돌린다. 공식 문서는 의미 있는 미커밋 변경이 있는 상태에서 머지하는 일을 말린다. 겹치는 미커밋이 있으면 시작 전에 중단할 수 있다.
깃허브가 나눠 둔 세 가지 합치는 법
호스팅 화면의 머지는 로컬 명령과 같은 말이지만, 이력을 남기는 방식이 갈린다. GitHub 문서는 머지 커밋, 스쿼시 앤 머지, 리베이스 앤 머지를 구분한다. 머지 커밋은 브랜치의 커밋을 모두 남기고 합친 지점을 명시한다. 스쿼시 앤 머지는 풀 리퀘스트의 커밋을 하나로 접어 베이스에 넣으며, 작은 수정 커밋이 많은 한 논리 단위에 맞다고 한다. 리베이스 앤 머지는 머지 커밋 없이 커밋을 베이스 위에 하나씩 올려 이력을 한 줄로 만든다. 스쿼시를 긴 수명의 브랜치에 반복하면, 이미 접어 넣은 커밋이 다음 풀 리퀘스트에 다시 보이며 같은 충돌을 반복할 수 있다고 GitHub는 적는다.
에이전트가 딴 줄을 메인에 넣는 순간
바이브 코딩에서 머지는 에이전트가 작업한 브랜치가 공유 이력의 일부가 되는 경계다. 한 세션의 커밋은 시도와 수정이 섞이기 쉽고, 그 사이 메인이 움직이면 같은 파일을 이미 다른 쪽이 고친 상태와 만난다. 화면이 되고 검사가 통과해도, 충돌 표시가 남은 채 합치면 메인에 미완성 파일이 들어간다. 풀 리퀘스트가 한 작업 단위라면 스쿼시로 이력을 접는 쪽이 GitHub가 말하는 용도와 가깝다. 커밋 하나하나가 이후에도 의미가 있으면 머지 커밋을 남긴다.
관련