힘내 병합을 사용하는 방법

Git은 안정적인 릴리스 브랜치가 오염되는 것을 방지하기 위해 브랜치를 사용하여 개발 스트림을 격리합니다. 브랜치의 작업을 메인 스트림으로 가져오는 것은 브랜치를 병합하는 것을 의미합니다. 방법은 다음과 같습니다.

Git에서 병합이란 무엇입니까?

Git은 분기를 간단하고 빠르게 만들도록 설계되었습니다. 다른 버전 제어 시스템과 달리 Git에서 분기하는 것은 사소한 문제입니다. 특히 다중 개발자 프로젝트에서 분기는 Git의 핵심 조직 도구 중 하나입니다.

분기는 다른 분기, 특히 기본 또는 마스터 분기의 코드에 영향을 주지 않고 코드를 수정하거나 추가할 수 있도록 새로운 개발 작업을 샌드박스에 넣습니다. 여기에는 일반적으로 안정적인 버전의 코드 베이스가 포함됩니다.

안정적인 코드 버전에서 이러한 변경 사항을 격리하는 것이 완벽합니다. 그러나 조만간 새 코드를 테스트하고 검토한 후 고무 스탬프를 찍어 마스터 브랜치로 롤백할 것입니다. 이 시점에서 브랜치를 마스터 브랜치로 병합해야 합니다.

관련 Git 브랜치는 어떻게 작동합니까?

실제로 분기에는 하위 분기가 있을 수 있으므로 분기를 마스터 분기 대신 다른 분기로 병합할 수 있습니다. 병합은 항상 하나의 분기를 취하여 해당 분기가 무엇이든 대상 분기로 병합한다는 점을 기억하십시오. 마스터 브랜치를 다른 브랜치로 병합하려는 경우에도 그렇게 할 수 있습니다.

대부분의 Git 작업과 마찬가지로 로컬 리포지토리에서 병합을 수행하고 원격 리포지토리로 푸시합니다.

Git에서 브랜치 병합 준비

로컬 Git 리포지토리와 원격 Git 리포지토리가 있는 소규모 개발 프로젝트가 있습니다. "master" 브랜치에서 "bugfix14"라는 브랜치를 만들고 버그에 대한 솔루션을 작업했습니다.

해당 작업이 완료되었으며 코드를 테스트했습니다. 모두 예상대로 작동합니다. 우리는 수정 사항이 소프트웨어의 다음 릴리스의 일부가 되도록 이러한 변경 사항을 마스터 분기로 롤링하려고 합니다.

병합을 수행하기 전에 수행해야 할 약간의 준비가 있습니다. 대상 브랜치(이 경우 "마스터" 브랜치)와 여기에 병합할 브랜치가 모두 최신 상태인지 확인해야 합니다.

이를 위해 git status 명령을 사용합니다.

 자식 상태 

• 분기 bugfix14 : 현재 분기입니다.
• 분기가 'origin/bugfix'로 최신 상태입니다 . 로컬 저장소의 분기는 원격 저장소의 분기와 동일한 커밋 기록을 가지고 있습니다. 그것은 그들이 동일하다는 것을 의미합니다.
• 커밋할 사항 없음 커밋 되지 않은 스테이징 영역의 변경 사항이 없습니다.
• working tree clean : 작업 디렉토리에 준비되지 않은 변경 사항이 없습니다.

이러한 모든 항목은 분기가 최신 상태이며 계속 진행할 수 있음을 나타냅니다. 이들 중 변경 사항이 있음을 나타내면 이를 스테이징하고 커밋한 다음 원격으로 푸시해야 합니다. 다른 사람이 이러한 파일에 대해 작업한 경우 원격 저장소에서 변경 사항을 가져와야 할 수 있습니다.

병합할 분기를 확인하면 병합 프로세스가 간소화됩니다. 또한 최신 버전인지 확인할 수 있습니다. 마스터 브랜치를 살펴보자.

 자식 체크 아웃 마스터

 자식 상태 

"마스터" 분기가 최신 상태라는 동일한 확인을 받습니다.

관련: 팀에 적합한 Git 워크플로 및 분기 모델을 선택하는 방법

병합 수행

병합하기 전에 커밋은 다음과 같습니다.

"bugfix14" 분기는 "master" 분기에서 분기되었습니다. "bugfix14" 브랜치가 생성된 후 "마스터" 브랜치에 대한 커밋이 있었습니다. "bugfix14" 브랜치에 몇 가지 커밋이 있었습니다.

두 개의 브랜치가 최신 상태인지 확인하고 "마스터" 브랜치를 확인했습니다. "bugfix14" 분기를 "master" 분기로 병합하는 명령을 실행할 수 있습니다.

 자식 병합 bugfix14 

병합이 발생합니다. "bugfix14" 브랜치는 여전히 존재하지만 이제 해당 브랜치에서 변경된 사항이 "마스터" 브랜치로 병합되었습니다.

이 경우 병합 명령은 3방향 병합을 수행합니다. 분기는 두 개뿐이지만 관련된 커밋은 세 개입니다. 그들은 두 가지 중 하나의 머리이며 병합 작업 자체를 나타내는 세 번째 커밋입니다.

원격 저장소를 업데이트하려면 git push 명령을 사용할 수 있습니다.

 자식 푸시 

어떤 사람들은 사이드 브랜치를 병합한 후 삭제하는 것을 선호합니다. 다른 사람들은 프로젝트의 실제 개발 역사에 대한 기록으로 이를 보존하기 위해 주의를 기울입니다.

브랜치를 삭제하려면 -d (삭제) 옵션과 함께 git branch 명령을 사용하면 됩니다.

 자식 분기 -d bugfix14 

원격 저장소에서 분기를 삭제하려면 다음 명령을 사용하십시오.

 git push origin --delete bugfix14 

선형 커밋 기록이 있지만 실제 기록은 아닙니다.

관련: 로컬 및 원격 리포지토리에서 Git 분기를 삭제하는 방법

Git에서 Fast-Forward Merge 수행

"마스터" 브랜치에 대한 커밋을 만들지 않은 경우 히스토리는 다음과 같습니다. "마스터" 분기의 끝에 연결되도록 개발 분기를 리베이스한 경우에도 이렇게 표시됩니다.

"master" 브랜치에는 커밋이 없기 때문에 "bugfix15" 브랜치를 병합하기 위해 Git이 해야 할 일은 "master" 헤드 포인터가 "bugfix15" 브랜치의 마지막 커밋을 가리키도록 하는 것입니다.

일반적인 git merge 명령을 사용할 수 있습니다.

 자식 병합 bugfix15

그것은 우리에게 이러한 결과를 제공합니다.

다음과 동일합니다.

이는 다음과 동일합니다.

Git은 가능할 때마다 빠른 병합을 수행합니다. "마스터" 브랜치에 대한 커밋이 빠른 병합이 불가능함을 의미하는 경우 Git은 3방향 병합 을 사용합니다.

fast-forward 병합을 강제 할 수는 없지만(결국 불가능할 수도 있음) fast-forward 병합을 하거나 아무것도 하지 않을 것이라고 선언할 수 있습니다. 가능한 경우 Git에 fast-forward 병합을 사용하도록 지시하고, 그렇지 않은 경우 3방향 병합을 수행하지 않도록 하는 옵션이 있습니다. 옵션은 --ff-only (고속 병합 전용)입니다.

이렇게 하면 "bugfix15" 분기가 "master" 분기로 병합되지만 빨리 감기 병합이 가능한 경우에만 가능합니다.

 git merge --ff-only bugfix15 

Git은 가능하지 않으면 불평하고 종료합니다.

 git merge --ff-only bugfix16 

이 경우 "마스터" 브랜치에 대한 커밋이 있으므로 빠른 병합이 불가능합니다.

Git에서 병합 충돌을 해결하는 방법

동일한 파일의 동일한 부분이 두 분기에서 변경된 경우 분기를 병합할 수 없습니다. 충돌하는 편집을 해결하려면 사람의 개입이 필요합니다.

여기에서 "bugfix17"이라는 분기에서 "master" 분기로 병합하려는 "rot.c"라는 파일을 변경했습니다. 그러나 "rot.c"는 "master" 브랜치에서도 변경되었습니다.

 자식 병합 bugfix17 

병합하려고 하면 충돌이 있다는 경고가 표시됩니다. Git은 충돌하는 파일을 나열하고 병합이 실패했음을 알려줍니다. --abort 옵션을 사용하여 완전히 취소할 수 있습니다.

 자식 병합 --중단

그러나 병합을 해결하는 것은 들리는 것처럼 두렵지 않습니다. Git은 우리를 돕기 위해 몇 가지 작업을 수행했습니다. 충돌하는 파일 중 하나를 편집하면(이 경우에는 하나만 있음) 충돌하는 코드 섹션이 강조 표시됩니다.

각 충돌은 7개의 보다 작음 문자 " <<<<<<< "와 7개의 보다 큼 문자 " >>>>>>> "로 제한되며, 그 사이에 7개의 등호 " ======= "가 있습니다. .

• 등호 위의 코드는 병합 하려는 분기에서 가져온 것입니다.
• 등호 아래의 코드는 병합 하려는 분기의 코드입니다.

7개의 문자 집합 중 하나를 쉽게 검색하고 파일을 통해 충돌에서 충돌로 이동할 수 있습니다. 각 충돌에 대해 유지할 편집 세트를 선택해야 합니다. 거부하는 코드와 Git이 추가한 7자 줄을 편집해야 합니다.

"bugfix17" 분기의 코드를 유지하겠습니다. 편집 후 파일은 다음과 같습니다.

이제 병합을 계속할 수 있습니다. 그러나 merge 명령이 아닌 commit 명령을 사용하여 이를 수행한다는 점에 유의하십시오.

평소와 같이 파일을 준비하고 커밋하여 변경 사항을 커밋합니다. 최종 커밋을 하기 전에 상태를 확인합니다.

 자식 추가 rot.c

 자식 상태

 git commit -m "병합된 bugfix17" 

병합이 완료되었습니다. 이제 이것을 원격 저장소로 푸시할 수 있습니다.

관련: Git 커밋을 수정, 편집 또는 실행 취소하는 방법(Git 기록 변경)

모든 것은 결국 합쳐진다

결국에는 모든 분기를 병합해야 변경 사항이 고아가 되어 잊혀지지 않습니다.

브랜치를 병합하는 것은 쉽지만 바쁘고 규모가 큰 팀에서는 충돌을 처리하는 것이 복잡해질 수 있습니다. 충돌을 해결하려면 코드의 기능과 변경 이유를 설명하기 위해 각 개발자의 입력이 필요할 수 있습니다. 유지할 편집 내용에 대해 정보에 입각한 결정을 내리기 전에 이를 이해해야 합니다.

슬프게도 Git은 이를 도와줄 수 없습니다.

관련: GUI Git 클라이언트를 사용해야 합니까?