Git 충돌 해결 파일만 스테이징하는 법

세 줄 요약

Git 2.56의 git add --resolved는 인덱스에 충돌 상태로 남아 있는 파일만 대상으로 삼는다.
선택한 일반 파일에 충돌 표시가 하나라도 남아 있으면 어느 파일도 스테이징하지 않는다.
같은 파일 안에 섞인 다른 수정까지 분리하지는 않으므로 커밋 전 변경 내용을 확인해야 한다.

충돌을 고친 뒤에는 git add --resolved

병합 충돌을 해결한 파일만 추가하고 싶다면 Git 2.56에서 git add --resolved를 사용할 수 있다. 9월 28일 공개된 새 버전은 충돌 해결을 등록하는 단계에서 관계없는 파일까지 함께 스테이징하지 않도록 선택 범위를 좁혔다.

예를 들어 config.ini의 충돌을 고치는 동안 notes.txt에도 메모를 남겼다고 하자. git add -u는 추적 중인 파일의 변경을 넓게 추가하지만, 새 명령은 인덱스에 아직 충돌 상태로 등록된 경로만 처리한다. 메모 파일은 충돌 파일이 아니므로 수정한 채로 남는다.

git --version
# 충돌 파일을 원하는 내용으로 수정한 뒤
git add --resolved

이 기능은 2.56에서 추가됐다. 명령을 인식하지 못한다면 먼저 사용하는 Git 버전을 확인해야 한다. 파일의 충돌 내용을 고르는 작업은 명령 실행 전에 끝내야 한다.

한 파일에 표시가 남으면 선택 범위 전체를 추가하지 않는다

git-add 공식 문서에 따르면 --resolved는 남아 있는 충돌 표시를 검사한다. 선택 범위의 일반 파일에서 표시를 발견하면 해당 파일을 알리고, 다른 파일도 추가하지 않는다.

따라서 충돌 파일 두 개 중 하나만 고쳤다면, 전체 명령을 실행해도 고친 파일이 먼저 등록되는 식으로 진행되지 않는다. 해결을 끝낸 경로만 먼저 등록하려면 파일을 명시한다.

git add --resolved -- config.ini

이 경우 검사는 선택한 경로 안에서 이뤄진다. 삭제로 해결한 파일이나 바이너리 파일도 대상이 될 수 있지만, 텍스트 충돌 표시 검사가 파일 내용의 정확성까지 판단해 주는 것은 아니다. --resolved는 -u나 -A와 함께 사용할 수 없다.

M이 어느 칸에 있는지 보고, 실제 diff를 읽는다

추가 결과는 git status --short로 확인한다. 상태 표시 규칙에서 충돌이 해결된 경로의 첫째 칸은 인덱스, 둘째 칸은 작업 파일의 상태다. 다음은 충돌 수정과 별도 메모가 남은 상태를 설명하는 예다.

M  config.ini
 M notes.txt

config.ini는 커밋할 변경으로 등록됐고, notes.txt는 작업 파일만 수정된 상태다. 반면 UU는 양쪽에서 수정된 미해결 충돌을 뜻한다. 충돌 중의 두 칸은 일반적인 스테이징 표시와 읽는 규칙이 다르다.

파일명만 보고 끝내지 말고 git diff --cached로 다음 커밋에 들어갈 내용을 확인한다. 새 명령은 이번에 추가할 파일을 좁히는 기능이다. 이미 스테이징된 다른 변경을 자동으로 빼 주지는 않는다.

충돌을 해결하는 판단과 파일 안의 변경 분리는 여전히 남는다

병합 절차는 충돌 내용을 원하는 결과로 고친 뒤 그 결과를 등록하고 커밋하는 순서다. --resolved는 이 가운데 등록 단계를 돕는다. 어느 쪽 코드를 남길지 선택하거나, 수정한 프로그램이 올바르게 동작하는지 검사하는 기능은 아니다.

또한 충돌 파일 안에 디버깅 코드까지 함께 넣었다면 그 내용도 파일의 현재 상태에 포함된다. 이름에 ‘resolved’가 있다고 충돌이 났던 줄만 골라 담지는 않는다. 일반 수정에서 변경 덩어리를 선택하는 git add -p와 목적이 다르다.

충돌 수정을 마치고 새 명령으로 등록한 다음, 스테이징된 diff를 읽고 프로젝트에 필요한 검증을 거쳐 커밋한다. 다른 파일의 작업을 남겨 두면서 병합 해결을 마무리할 때 이 순서가 유용하다.