1. Git 브랜치(Branch)란 ?
모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다.
git-scm
- Branch란 각자 독립적인 작업 영역(스냅샷) 안에서 자유롭게 소스코드를 변경하고 이렇게 분리된 작업에서 변경을 원래의 버전과 비교를 하여 병합(Merge) 할 수 있습니다.
- 위의 예시이미지와 같이 자신이 독립적으로 나눈 영역을 원래의 버전에 병합은 물론 다른사람이 나의 작업영역에 기능을 추가하여 병합하는것또한 가능합니다.
2. Merge
오늘 글의 주된 주제입니다 앞서 브랜치에대해 설명을 잠깐 한 것은 Merge 기능을 사용하기전 필수적으로 알아둬야할 선행지식이기 때문입니다.
💡 1. Fast-foward Merge
1-1. 어떠한 경우에 적용되는지?
Fast-foward Merge는 베이스에서 하나의 커밋이 분기점으로 생기고 베이스에는 다른 수정사항 없이 커밋에만 수정사항이 발생후 Merge시 사용됩니다.
1-2. 어떠한 강점이 있는지?
단순히 Main Branch에서 분리된 다른 Branch를 최신버전으로 Head가 이동되기때문에 Marge Commit 이력이 남지 않습니다.
해당 이미지를 봐봅시다 !
1. Master Branch 에서 B까지 커밋후 새로운 브런치(B 라고 하겠음) 분기점 발생
2. B브런치에서 Y까지 커밋후 Merge시 Master의 변경점이 없음으로 Master과 B(feature)의 Head가 모두 Y를 가르킵니다.
💡 2. 3-Way Merge
2-1. 어떠한 경우에 적용되는지?
3-way Merge는 서로 다른 두 브랜치에서 동시에 변경 사항이 발생하고, 이 두 브랜치를 병합할 때 사용됩니다. 두 브랜치의 커밋 히스토리가 갈라져 있는 경우에 3-way Merge가 필요합니다.
2-2. 어떠한 강점이 있는지?
3-way Merge는 동시에 변경 사항이 발생한 두 브랜치를 효과적으로 병합할 수 있으며, 병합 커밋을 생성하여 변경 사항을 통합합니다. 이로써 동시에 변경이 발생한 부분을 효과적으로 병합할 수 있으며, 변경 이력을 보다 정확하게 관리할 수 있습니다.
2-3. 3-Way Merge의 필수조건
✔️ 1. 두개의 브랜치의 공통되는 조상커밋(Base)
✔️ 2. 다르게 작업중인 브랜치 1
✔️ 3. 다르게 작업중인 브랜치 2
➰ 이것을 합쳐 3-Way Merge라고 합니다.
해당 이미지를 봐봅시다 !
1. 베이스 커밋에서 두개의 커밋파생
2. feature1 커밋은 베이스의 변경점없이 그대로 이어져 Fast-foward Merge로 진행
3. feature2 의 커밋은 두번째과 세번째 커밋의 사이에 베이스의 변경이 일어남 3-Way Merge 진행
💡 3. Squash and merge
3-1. 사용방법
앞으로 소개할 Squash and Merge 와 Rebase 는 앞에서말한 Fast-Foward Merge 와 3-Way Merge 와 다르게 터미널에 직접 명령어를 입력해야합니다.
- 사용방법 -
git merge --squash my-branch // git merge <옵션> <브랜치이름>3-2. Squash and merge의 특징
✔️ 장점
- 여러번 커밋한 이력을 ' 하나 ' 로 합친후 Merge 합니다.
- 서브브랜치들을 합쳐줘 깔끔한 이력관리가 가능합니다.
✔️ 단점
- 개별 커밋의 세부 정보가 손실되기 때문에, 커밋 별로 변경 내용을 따로 복구하기 어려울 수 있습니다.
- 개별 커밋의 작성자, 날짜 및 메시지 정보는 단일 스쿼시된 커밋으로 이동하므로, 개별 커밋에 대한 자세한 히스토리 정보가 더 이상 확인되지 않을 수 있습니다.
기존 마스터브랜치(init) 에서 파생된 새로운 브랜치에서 A => B => C 를 진행후 다시 마스터브랜치에서 해당 브랜치를 Merge --squash를 시도하면 init 브런치와 A,B,C 브런치 하나가 생성됩니다.
여기서 주의점은 A,B,C의 브런치가 생성이 된다는것은 그 전의 A,B,C에 대한 모든 히스토리와 정보가 날라가며 하나의 커밋으로 병합된다는점 입니다.
오른쪽 상단의 그래프에는 11 12 13 의 변경내역이 보이지만 밑의 log를 확인해보니 로그가 전체다 삭제되고 squash라는 이름의 브랜치로 통합된모습 (squash는 저가 지정한 이름입니다.)
💡 4. Rebase and merge
4-1. 사용방법
- 사용방법 -
git rebase my-branch // git rebase <브랜치이름>4-2. Rebase and merge의 특징
✔️ 장점
- 히스토리가 단순해져 가독성이 좋아집니다.
- 협업의 규모가 커져 여러개발자들이 브런치를 합칠때 깔끔하게 유지 할 수 있습니다.
✔️ 단점
- 충돌시 수정이 어렵습니다. 예를들어 프로젝트 진행중 다른 팀원이 Push한 작업물을 내가 가져와 작업중 Rebase를 사용한다면 다른 팀원들이 작업한 작업물들과 커밋위치가 전체 바뀌어져 혼란을 초례 할 수 있습니다.
말 그대로 Re(다시)Base(베이스) 다시 베이스를 만든다는 뜻 입니다.
위의 이미지를 예시로 보면 A=>B 이후 C와 D로 분기점이 나눠지는데 이때 Master (A=>B커밋이 진행되는 브런치) Rebase C 를 하면 C를 기점으로 다시 베이스가 지정되는것입니다.
이때 C의 작업내용은 B의 최신내용에 합쳐져 베이스를 만듭니다!
중요한 Point는 Squash는 여러 커밋을 합쳐서 하나의 커밋으로 만들지만 이력또한 다 사라져 깔끔 할 수 있으나 위험할수 있으며 Rebase는 여러커밋을 Head 커밋을 기준으로 Base를 다시 설정하며 이력을 보존해준다는 점입니다.
1이 MAIN의 브런치이며 11~13이 '11(브런치이름)'의 브런치입니다. main을 기준으로 베이스 다시 나눠진게 보이시나요 ??
2023-10-28 Git - Branch Merge
