CHAPTER 07. 브랜치 더 깊게 파기-얄코의 too much 친절한 깃&깃허브

CHAPTER 07. 브랜치 더 깊게 파기

LESSON 23. fast forward vs 3-way merge

fast forward
변경 사항이 더 최근인 브랜치로 통합하는 방법
예를 들어 a,b브랜치가 공통 커밋을 조상으로 갖고있고 b브랜치에만 이후의 커밋이 있다면
두 브랜치를 병합하기위해 다른 새로운 커밋을 만들지 않고 a브랜치의 해드를 b브랜치의 최신 커밋으로 옯긴후 병합된 b브랜치는 삭제

fast forward방식의 단점 : 어떤 브랜치를 사용했고 언제 병합했는지 기록이 남지않는다는 것
이러한 단점때문에 fast forward하지않고 커밋을 만들어서 병합하려면 git merge --no-ff옵션을 붙여서 명령하기도 함->ff는 fast forward의 약자

git merge --no-ff

3-way merge
공통 조상 커밋을 기준으로 두 개의 브랜치를 자동으로 통합하는 방법
이 경우 두 브랜치 모두 커밋된 마디가 하나 이상 잇는 상태이므로 별도의 병합 커밋을 하나 만드는 방식으로 병합
a,b브랜치를 병합할 떄 두 브랜치의 최신 커밋 모두에 속하는 어떤 파일이 a브랜치에서 변경되었는지 b브랜치에서 변경되었는지,
혹은 두 브랜치 모두에서 변경되었는지 확인해서 충돌이 일어나는 상황인지 판단해야 함
이것을 판별하기 위해 두 브랜치의 공통 조상이 되는 커밋에서 a,b 브랜치의 커밋을 비교하기 때문에 총 세 커밋을 비교한다는 의미로 3-way merge라고 부름.
차이가 있는 파일마다 어떤 것을 병합에 반영할지, 어떤 것을 충돌로 인식해서 사용자가 해결하도록 맡겨야할지를 병합 커밋에서 결정

LESSON 24. 다른 브랜치에서 원하는 부분만 가져오기

체리픽으로 원한느 커밋만 따오기

체리픽 : 여러 브랜치가 있을 때 다른 브랜치에서 원하는 커밋만 딱 골라서 가져오는 것

브랜치의 커밋 해시값을 가져와 main브랜치로 이동후 체리픽을 해줌

git cherry-pick (커밋 해시값)

메인 브랜치의 cherry커밋과 fruit 브랜치의 cherry커밋은 별개의 커밋
머지나 리베이스와 달리 특정 커밋을 복제해서 가져오는 것

다른 가지의 잔가지 가져오기

git rebase --onto (도착 브랜치) (출발 브랜치) (이동할 브랜치)

 

rebase --onto를 되돌리기
git reflog명령으로 내역을 살펴보면 git rebase --onto명령에 따라 여러 작업이 진행된 내역을 볼 수 있음

git reflog

 

전체 브랜치의 상태를 rebase --onto이전으로 되돌리기
1.해당 브랜치가 옮겨지기 전 마지막 커밋인 부분을 reflog에서 찾아 reset --hard
2.rebase --onto를 사용해서 citrus커밋들을 main으로부터 다시 fruit브랜치의 orange부분으로 옮김
orange커밋으로 체크아웃한다음 그곳에서 새브랜치를 만들고 두 커밋들을 해당위치로 옮겨 붙이기

다른 가지의 커밋을 하나로 묶어서 가져오기

1.아래 명령어 실행

git merge --squash (가져올 브랜치)

 

2.가져올 브랜치의 변경사항이 스테이지영역에 있는 상황->commit 진행

 

3. squashed commit of the following이라는 커밋이 생김->해당 커밋을 클릭하면 자세한 변경사항 확인 가능

스쿼시와 머지의 차이

스쿼시와 머지는 실행 후 코드의 상태는 같지만 세부내역이 다름
a,b를 머지했다면 두브랜치를 한곳으로 이어붙인것
스쿼사는 b브랜치의 마디(커밋)를 복사한 후 하나의 커밋으로 모아서 a브랜치에 스테이지된 상태로 붙이는 것->add하는 것
스쿼시를 한뒤 별도로 커밋을 해야 변경사항이 온전히 반영됨

LESSON 25. 협업을 위한 브랜치 활용법

깃 플로란 오늘날 it기없에서 소프트웨어 개발 팀원의 협업을 위해서 브랜치를 활용하는 하나의 방법론
기능개발을 위한 feature브랜치
안정적인 배포를 위한 release브랜치
유지보수를 위한 hotfix브랜치등을 활용하여 효율적인 협업과 지속적인 개발/배포를 하는데, 팀의 프로젝트나 성격에 맞게 변형하기도 함

브랜치	용도
main	제품 출시 / 배포
develop	다음 출시 / 배포를 위한 개발 진행
release	출시 / 배포 전 테스트 진행(QA)
feature	기능 개발
hotfix	긴급한 버그 수정

 

깃 플로 방식

main브랜치에는 실제로 출시되어 사용자들에게 선보이는 버전이 최종적으로 머지됨->태그마다 v0.1,v0.2처럼 버전이 표기

 

개발작업은 develop브랜치에서 진행되어 새로운 기능을 추가하거나

어떤 부분을 수정하거나 문제가 있는 부분을 고치는 식으로 커밋을 줄줄이 추가해 나감

 

그 과정에서 굵직한 과정은 feature브랜치를 여러개 만들어 진행
feature브랜치의 기능이 완성되면 develop브랜치로 보내서 개발 진행

 

어느정도 개발하다가 다음버전으로 출시해도 될것 같을 때는 release브랜치로 옮김

 

release브랜치에서 작업한 내용이 테스트를 거치면서 수정사항이 생기면 develop브랜치에서 작업

 

검증과정을 거쳐 출시해도 되겠다고 판단되면 main브랜치로 옯겨 출시

 

출시한 버전에서 오류가 발견되면 당장 고쳐야하는데 이떄 hotfix브랜치를 사용
예를 들어 v0.1에서 어던 오류가 나오면 재빨리 hotfix브랜치에서 문제를 해결하고 main브랜치에 병합해서 v0.2로 올림