Git 병합은 서로 다른 개발 흐름에서 만든 변경을 하나의 이력으로 합치는 작업이다. 브랜치의 관계에 따라 포인터만 이동할 수도 있고, 두 흐름을 연결하는 새 커밋이 만들어질 수도 있다. 소스가 자동으로 합쳐졌다는 사실과 프로그램이 올바르게 동작한다는 사실은 별개다. Git 병합 문서
두 가지 기본 상황
기준 브랜치가 분기 이후 바뀌지 않았다면, 새 변경이 있는 커밋으로 이동하는 빠른 감기 방식이 가능하다. 두 브랜치 모두 변경되었다면 일반적인 병합은 공통 조상과 양쪽 끝의 내용을 비교한다. 이렇게 만든 병합 커밋에는 여러 부모가 있어, 분기했던 흐름이 합쳐진 지점을 이력에서 확인할 수 있다.
| 상황 | 일반적인 결과 |
|---|---|
| 한쪽 이력이 다른 쪽의 연장선 | 빠른 감기 가능 |
| 공통 조상 이후 양쪽이 변경됨 | 변경 결합과 병합 커밋 |
| 같은 부분을 양쪽에서 다르게 수정 | 수동 충돌 해결 필요 가능 |
충돌을 해결할 때
예를 들어 한 브랜치는 로그인 오류 메시지를 바꾸고 다른 브랜치는 같은 위치에 번역 처리를 넣을 수 있다. 어느 한쪽을 무조건 선택하기보다 메시지 변경과 번역 의도를 함께 반영해야 한다. 충돌 표시를 제거한 뒤 결과를 스테이징하고 병합을 마무리한다. 해결 과정에서는 관련 작성자와 변경 목적을 확인하는 것이 좋다. 충돌과 병합 상태의 처리 원리는 merge 명령 문서를 참고할 수 있다.
병합 이후 확인
충돌이 없더라도 함수 인자 변경과 호출 코드가 어긋나는 논리적 문제가 남을 수 있다. 단위 테스트뿐 아니라 변경이 만나는 경계의 통합 테스트도 확인한다. 병합 결과의 차이를 다시 읽고, 자동화가 검사한 커밋과 실제 합친 커밋이 일치하는지 살펴야 한다. 선형 이력을 만드는 리베이스와 어느 쪽이 더 좋은지는 팀의 이력 정책과 공유 상태에 따라 달라진다.