병합 충돌이란 무엇일까요?
여기에서는 개발자가 병합 충돌 해결을 이용하여 겹치는 원본에서 최상의 결과를 도출하는 방법을 설명 합니다.
GitHub 흐름
GitHub는 공동 소프트웨어 개발용 플랫폼을 제공할 뿐만 아니라 다양한 자체 기능을 최적화하도록 설계된 정해진 워크플로도 제공합니다. 이 단원의 주제는 병합 충돌이지만 GitHub 흐름 이해하기를 먼저 살펴보는 것이 좋습니다.
분기 병합
개발자가 main를 바탕으로 feature-branch라는 분기를 만들고 커밋 두 개를 만드는 시나리오를 상상해 보세요. 이 작업을 진행하는 동안 다른 사용자가 관련 없는 끌어오기 요청을 main에 병합합니다. 개발자가 feature-branch를 main에 다시 병합하려고 하면 어떻게 될까요?
정답은 경우에 따라 다르다입니다.
feature-branch가 main에서 만들어졌지만 분기 자체를 기반으로 하지 않았습니다. 해당 시점의 main의 HEAD 커밋을 바탕으로 합니다. 그 이후 main에 적용된 모든 커밋을 인식하지 못합니다. 현재 추적하고 있는 커밋은 최근 변경 내용을 덮어쓰지 않고는 반드시 분기의 현재 상태로 폴딩되지는 않습니다.
feature-branch 커밋이 분기 생성 후 main에 적용된 병렬 커밋과 중첩되지 않는다면 아무 문제도 없습니다. 새로운 파일을 추가할 수 있습니다. 변경하지 않은 파일은 삭제할 수 있습니다. main에서 변경된 코드 줄은 feature-branch 생성 후 병렬 작업 때문에 변경되지 않았다면 feature-branch에서 변경할 수 있습니다.
하지만 두 커밋 집합에 같은 코드 줄에 대한 변경 사항이 포함된다면 어떨까요? 이러한 병합 시도는 병합 충돌 때문에 실패하게 됩니다.
병합 충돌이란 무엇일까요?
병합 충돌은 개발자가 실수로 병렬 변경 사항을 덮어쓰게 될 변경 사항을 병합하려고 하면 발생합니다. 다른 변경 사항을 기본 분기로 병합한 방법은 중요하지 않습니다. Git은 한 변경 내용을 다른 변경 내용에 자동으로 덮어쓰지 않습니다. 대신 병합을 시도하는 사용자에게 이를 통보하여 비교 분기에서 해결한 다음 다시 병합을 시도하게 합니다.
병합 충돌 해결
병합 충돌을 해결하는 데 도움이 되도록 GitHub에서는 각 분기의 차이점을 포함하는 임시 하이브리드 파일을 생성합니다. 기본 규칙은 비교 분기의 텍스트를 기본 분기 위에 일련의 등호(=======)로 구분하여 표시하는 것입니다.
변경 사항이 사소하다면 이 보기를 사용하여 파일을 직접 편집할 수 있습니다. 보관하기로 결정하면 최종 결과가 비교 분기에 커밋됩니다. 더 복잡한 병합이라면 다른 개발 도구를 사용하는 방법이 효율적입니다. 어떤 방법을 사용하더라도 커밋하기 전에 코드에서 분기 표식을 제거해야 한다는 사실을 명심하세요. 충돌 해결을 커밋할 때 이러한 표식을 제거하는 것을 잊으면 해당 표식은 파일에 그대로 남아 메모 처리되지 않습니다.
참고 항목
이번 단원에서는 브라우저 컨텍스트 내에서 병합 충돌을 해결하는 방법을 설명합니다. Visual Studio를 비롯한, 통합적인 병합 출동 해결 경험을 제공하는 수많은 개발 플랫폼이 존재합니다.
모든 병합 충돌이 분기에서 해결되면 병합을 다시 시도할 수 있습니다.
병합 충돌 방지
방지할 수 없는 병합 충돌도 있습니다. 모든 병합은 승인 대기 중인 다른 끌어오기 요청에 대한 병합 충돌을 유발할 수 있습니다. 하지만 분기를 자주 끌어오면 병합 충돌의 복잡성을 효과적으로 줄일 수 있습니다.
초기에 자주 끌어오기
git pull 명령은 현재 분기에 아직 적용되지 않은 모든 기본 분기 커밋을 끌어옵니다. 여러 버전 제어 시스템에서 로컬 코드를 최신 버전으로 업데이트하는 데 사용하는 Get Latest 명령과 개념적으로 비슷합니다. 분기에 대한 업데이트를 끌어오면 분기가 만들어진 이후(또는 마지막으로 끌어온 이후) 발생한 모든 변경 내용을 병합하게 됩니다.
분기에 업데이트를 끌어오면 병합 충돌이 발생할 수 있지만 괜찮습니다. 어차피 나중에 문제가 생길 텐데, 일찍 생기면 해결하기가 더 쉽습니다.
업데이트 끌어오기는 병합 충돌의 영향을 완화하는 효과도 있지만 사용자가 작업하면서 커밋된 변경 사항을 분기에 통합하는 기능도 제공합니다. 이렇게 하면 이전에 발생 가능한 문제를 조기에 해결할 수 있습니다. 예를 들어, 다른 파일에서 클래스 정의가 변경되어 코드가 더 이상 컴파일되지 않을 수 있습니다. 이 변경으로 인해 나중에 병합할 때 병합 충돌이 발생하지는 않지만, 먼저 테스트하지 않으면 빌드가 손상됩니다. 업데이트 끌어오기를 자주 수행하여 분기를 기본 분기와 최대한 비슷하게 유지하는 것이 좋습니다.
Git 다시 지정을 이용해 기록을 깔끔하게 유지
git rebase(또는 git pull --rebase) 명령은 분기 기록을 다시 작성하여 기본 분기의 현재 HEAD 커밋을 자체 기반으로 사용하는 것입니다. 즉, 사용자의 분기는 기본 분기의 현재 상태에서만 분기된 것처럼 동작하도록 업데이트됩니다. 이 기준 주소 다시 지정은 모든 변경 내용을 원래 분기에서 가져온 커밋이 아닌 기본 분기의 최신 상태와 비교한다는 것을 의미합니다. 기준 주소 다시 지정은 결과적으로 최종 병합이 끝나면 기록을 추적하기가 쉬워집니다. 커밋은 이전의 병렬 커밋을 선형적으로 따르기 때문입니다. 모범 사례는 업스트림을 병합하기 직전에 분기를 다시 지정하는 것입니다.
Git 다시 지정 정보 및 Git 다시 지정 후 병합 충돌 해결에 대해 자세히 알아보세요.