이 사이트의 실습은 자바스크립트를 켜야 움직입니다. 아래는 같은 내용을 글로 적은 것입니다.
공부 › 아키텍처와 운영 › 협업
merge와 rebase
두 브랜치를 합치는 세 가지 모양
feature 브랜치에서 작업하는 동안 main에도 새 커밋이 생겼습니다. 이 둘을 합칠 때 merge를 쓰느냐 rebase를 쓰느냐에 따라 커밋 그래프의 모양이 달라지고, 같은 줄을 고쳤다면 충돌이 납니다.
실행으로 대조 · git 2.55로 임시 저장소를 만들어 확인
이 실습에 나오는 개념
- merge와 rebase
- 두 브랜치의 변경을 합치는 두 가지 방법이다. merge는 양쪽의 이력을 그대로 두고 합친다(이력이 갈라져 있으면 병합 커밋이 생기고, 갈라지지 않았으면 브랜치 포인터만 앞으로 옮긴다). rebase는 내 커밋들을 대상 브랜치의 최신 지점 뒤로 옮겨 다시 적용해 이력을 한 줄로 만든다. rebase는 기존 커밋을 새 커밋으로 다시 만드는 것이어서 이미 다른 사람과 공유한 커밋에는 사용하지 않는다.
- Git 충돌(Conflict)
- 두 브랜치가 같은 파일의 같은 부분을 서로 다르게 수정해 Git이 자동으로 합치지 못하는 상황이다. 충돌이 표시된 부분을 확인해 어느 쪽을 반영할지 또는 둘을 어떻게 합칠지 사람이 직접 결정해 수정한 뒤 병합을 마무리한다.
- Git의 fetch, pull, push
- fetch는 원격 저장소의 새로운 변경 내용을 내려받되 내 작업 브랜치에는 반영하지 않는 것이다. pull은 fetch에 더해 내려받은 변경을 현재 브랜치에 합치는 것까지 수행한다. push는 내 로컬의 커밋을 원격 저장소로 올리는 것이다.
- Git Flow와 GitHub Flow
- 브랜치를 운영하는 전략이다. Git Flow는 출시용 브랜치와 개발 통합 브랜치를 두고 기능, 출시 준비, 긴급 수정을 각각의 브랜치로 관리하는 방식으로, 정해진 주기로 버전을 출시하는 제품에 맞는다. GitHub Flow는 기준 브랜치 하나에서 짧은 작업 브랜치를 만들어 리뷰 후 합치고 바로 배포하는 단순한 방식으로, 수시로 배포하는 서비스에 맞는다.
- 코드 리뷰와 Pull Request
- Pull Request(PR)는 작업한 브랜치의 변경을 기준 브랜치에 합쳐 달라고 요청하는 것이다. 코드 리뷰는 합치기 전에 다른 개발자가 변경 내용을 검토하는 과정으로, 결함을 일찍 발견하고 코드의 일관성을 유지하며 팀 안에서 지식을 공유하는 효과가 있다.
이렇게 바꿔 보세요
- 처음 설정으로 — merge. 두 갈래를 잇는 병합 커밋이 생깁니다.
- rebase 후 합치기 — feature의 커밋을 main 끝으로 옮겨 붙입니다. 한 줄로 이어집니다.
- main에 새 커밋이 없으면 — 병합 커밋 없이 main이 앞으로 이동만 합니다(fast-forward).
- 같은 줄을 고쳤다면 — 충돌이 납니다. 사람이 골라 줘야 합니다.
- 이미 올린 브랜치를 rebase하면 — 원격의 커밋과 달라져 강제로 올려야 합니다.
- squash — feature의 커밋 여러 개를 하나로 뭉쳐 main에 올립니다.
처음 설정으로 실행하면
- 시작 상태입니다. feature 브랜치는 커밋 B에서 갈라져 D, E 두 커밋을 쌓았습니다. 그 사이 main에는 다른 사람이 올린 커밋 C가 생겼습니다.
- C와 E의 내용을 합친 새 커밋 M이 만들어집니다. M은 부모가 둘(C와 E)인 병합 커밋입니다. 기존 커밋 D와 E는 그대로이고, 언제 갈라져 언제 합쳐졌는지가 그래프에 남습니다.
실행 결과
- merge는 기존 커밋을 건드리지 않고 병합 커밋을 하나 추가합니다. 이력이 사실 그대로 남지만, 브랜치가 많으면 그래프가 복잡해집니다.
코드
git switch main
git merge feature
이 모형의 전제
커밋 다섯 개짜리 작은 저장소 예시입니다. 충돌은 한 파일의 한 곳에서만 난다고 가정했습니다. 각 명령의 동작은 Git 공식 문서(git-merge, git-rebase)의 설명을 따랐습니다. 팀에 따라 병합 방식(merge commit, squash, rebase)을 정해 두고 쓰며, 어느 쪽이 옳다기보다 이력을 어떤 모양으로 남길지의 선택입니다. 이 PC의 git 2.55로 임시 저장소를 만들어 확인했습니다. merge는 부모가 둘인 병합 커밋을 만들고 기존 커밋의 해시를 유지했으며, main에 새 커밋이 없을 때는 fast-forward였습니다. rebase 뒤에는 D와 E의 해시가 바뀌고 병합 커밋 없이 한 줄이 됐으며, 이미 올린 브랜치는 일반 push가 거부되고 강제 push가 필요했습니다. squash 커밋은 부모가 하나였고 git은 feature가 합쳐졌다고 인식하지 않았습니다. 충돌 표시도 화면의 모양 그대로였습니다.
앞 실습: 분산 추적