Git merge의 두가지 전략
- Fastforward
- 3-way-merge
rebase때 브랜치를 옮겨 붙인 후 헤드를 옮기기 위해 merge를 사용하였음
fastforward의 경우 두 브랜치가 공통 커밋을 조상으로 가지고 있는데 한쪽 브랜치에만 커밋이 있을 시 굳이 이둘을 병합하기 위한 다른 커밋을 만들지 않고 A브랜치의 헤드를 B브랜치로 옮기는 것
이후 병합 된 브랜치를 없앰
-> 하지만 어떠한 브랜치를 사용하고 언제 병합했는지 기록이 남지 않음
기록을 남기기 위해 병합 커밋을 만들어서 merge 하려면
git merge --no-ff (병합할 브랜치 명)
-> 그냥 merge 시에는 fastforward 방식으로 동작
3-way merge의 경우 git은 변경사항이 조상으로 부터 A브랜치에서 변경된건지, B 브랜치에서 변경된건지, 양쪽에서 모두 변경되어 충돌이 일어나는건지 상황 판단을 해야 함
-> 이는 A,B 커밋만으로 판단할 수 없다
-> 이를 판별하기 위해 두 브랜치의 공통 조상이 되는 커밋의 내용(첫번째 위치한 커밋)과 A,B를 대조해서 판단
Cherry Pick
다른 브랜치에서 원하는 커밋만 따오기(cherry pick)
git cherry-pick cadfd026adb861cef437c612fe4f3ef519bf256f체리의 해시 코드만으로 cherry를 main에 복사해 오는 코드
-> fruit 브랜치의 cherry가 사라지는 것이 아님(merge,rebase)와 다름
다른 브랜치에서 파생된 브랜치 가져오기
git rebase --onto (도착 브랜치) (출발 브랜치) (이동할 브랜치)fruit branch 작업 내용은 사용하지 않지만 citrus 작업 내용만 사용할려는 경우
fruit 브랜치에서 파생된 citrus 브랜치를 main 브랜치로 옮겨붙이기
-> git rebase --onto main fruit citrus
이후 main 브랜치를 위로 올리기 위해
다른 커밋들을 하나로 묶어서 가져오기
git merge --squash (대상 브랜치)root 브랜치에 커밋을 모아 하나의 커밋으로 추가하고 싶은 경우
-> 커밋이 되진 않음(stage 만)
-> 따로 커밋 해주고 나면
기존의 root 브랜치는 사라지지 않음
일반 merge와 merge --squash는, 실행 후 코드의 상태는 같지만 내역 면에서 큰 차이
- 일반 merge : A와 B 두 브랜치를 한 곳으로 이어붙임
- merge --squash : B 브랜치의 마디들을 복사해다가 한 마디로 모아 A 브랜치에 붙임 (staged 상태로)
협업을 위한 브랜치 사용법
Gitflow -> 협업을 위한 브랜칭 전략
main(master)브랜치에는 최종적으로 선보여질 버전이 최종적으로 커밋됨
개발작업은 develop 브랜치에서 진행
-> 기능 추가 및 문제 해결
feature는 보통 큰 기능 개발할 때 분기해서 작업
-> 이후 develop으로 merge
개발 후 이정도면 출시할만할것 같다 할 때 release 브랜치로 옮김
-> 테스트 및 검증
-> 검증 후 main으로
기존의 출시된 버전에서 오류 발견 시
-> Hotfix 브랜치 사용
