머지 (Merge)

머지(Merge)는 나뉘어 진행된 변경을 하나의 작업 이력이나 결과로 합치는 작업입니다. Git에서는 다른 브랜치의 변경을 현재 브랜치에 통합하는 뜻으로 주로 씁니다. 두 브랜치가 어디에서 갈라졌는지와 각각 무엇을 바꿨는지에 따라 합치는 방식이 달라지며, 자동으로 결정할 수 없는 부분은 충돌로 남습니다.

공통 이력에서 변경을 합치는 과정

Git의 머지 명령 문서는 다른 커밋 이후의 변경을 현재 브랜치에 반영하는 과정을 설명합니다. 기능을 개발하는 브랜치와 기본 브랜치가 따로 진행됐다면, 두 이력의 공통 조상과 양쪽 끝의 내용을 바탕으로 통합합니다. 작업자가 파일을 직접 복사하는 것과 달리 어떤 변경 이력이 합쳐졌는지도 버전 관리 기록에 남길 수 있습니다.

현재 브랜치가 상대 브랜치의 조상이라면 중간에 별도로 갈라진 변경이 없습니다. 이때 가능한 패스트포워드는 현재 브랜치가 가리키는 위치를 앞으로 옮기는 방식입니다. 새로운 병합 커밋을 만들지 않고도 상대 브랜치까지의 변경이 반영됩니다. 브랜치 이름 두 개가 있었다는 사실만으로 항상 두 갈래 이력을 합치는 커밋이 생기는 것은 아닙니다.

양쪽에서 별도 커밋을 만들었다면 보통 두 이력을 연결하는 병합 커밋이 필요합니다. 이 커밋은 합쳐진 결과와 둘 이상의 부모 커밋을 기록합니다. 어떤 작업을 통합했는지 나중에 따라갈 때 이 연결이 단서가 됩니다. 실제로 사용할 전략은 프로젝트의 이력 관리 방식과 명령 옵션에 따라 달라지므로, 파일 내용과 커밋 구조를 함께 확인합니다.

충돌과 동작 오류의 차이

Pro Git의 브랜치 병합 설명은 같은 파일의 같은 부분을 서로 다르게 수정했을 때 자동 병합이 멈추는 사례를 보여 줍니다. 이때 작업자는 충돌한 부분을 읽고 최종 내용을 결정한 뒤 해결한 파일을 기록합니다. 한쪽 버전을 무조건 고르는 것보다 양쪽 변경의 목적을 확인하는 과정이 필요합니다.

한 브랜치가 함수 이름을 바꾸고 다른 브랜치가 예전 이름을 쓰는 호출을 추가했다면, 텍스트를 합치는 과정에서 충돌이 표시되지 않아도 실행은 실패할 수 있습니다. Git의 자동 병합 성공은 파일 차이를 결합했다는 결과입니다. 합쳐진 코드가 사용자의 요구대로 동작하는지는 테스트와 실행 확인으로 따로 판단합니다. 변경이 여러 파일에 걸쳐 있을수록 함수의 호출 관계와 데이터 형식도 검토 대상이 됩니다.

충돌을 해결하면서 기존 기능을 빠뜨리는 경우도 있습니다. 화면 표시를 고친 쪽과 접근 권한을 고친 쪽이 같은 조건문을 수정했다면 두 요구가 모두 최종 코드에 남아 있는지 읽습니다. 충돌 표시를 지운 뒤 파일이 문법적으로 유효하다는 사실만으로 이 검토를 대신할 수는 없습니다. 관련 테스트가 각 변경의 의도를 확인하는지 살피면 해결 과정에서 빠진 조건을 찾는 데 도움이 됩니다.

PR 병합 방식과 작업 상태

GitHub의 PR 병합 문서는 병합 커밋을 만드는 방식 외에 스쿼시와 리베이스 병합도 제공합니다. 스쿼시는 작업 브랜치의 변경을 하나의 커밋으로 묶고, 리베이스 병합은 변경들을 대상 브랜치 위의 새 커밋으로 이어 붙입니다. 서비스 화면에서 모두 병합 동작으로 제공하더라도 커밋의 식별자와 이력이 보존되는 방식은 같지 않습니다.

풀 리퀘스트는 변경을 제안하고 검토하는 단위이며, 머지는 승인한 변경을 통합하는 작업입니다. PR 없이 로컬에서 머지를 할 수도 있고 PR을 열어 둔 채 병합하지 않을 수도 있습니다. 머지한 브랜치를 원격으로 보냈는지, 그 버전이 실제 배포됐는지도 별도의 상태입니다. 작업 결과를 공유할 때는 로컬 통합과 원격 반영을 구별하면 협업자가 확인할 위치가 분명해집니다.

병합을 시작하기 전에 저장하지 않은 작업과 커밋하지 않은 변경을 확인하는 이유도 여기에 있습니다. 기존 수정이 섞이면 충돌 원인을 구별하거나 중단 전 상태를 되찾기 어려워집니다. git merge --abort는 진행 중인 병합을 중단하는 명령이지만, 시작 전에 커밋하지 않은 변경이 있었다면 항상 원상 복원을 보장하지는 않는다고 Git 머지 문서는 설명합니다. 작업 상태를 기록하고 변경을 보존한 뒤 통합하면 재검토할 기준이 남습니다.