[git]책 - 팀개발을 위한 git, github 시작하기(2일차)

1일 차는 혼자 버전관리 하고 원격저장소를 다루는 것까지 배웠다.

2일 차는 여러 명과 버전관리를 하기 위해 브랜치, 머지, 풀의 개념에 대해 배운다.

 

1일 차는 나 혼자 버전관리를 하기 때문에 로컬, 원격 main브랜치를 넘나들며 최신, 구버전만 

구분하며 작업을 해도 된다.

하지만 여러명이 작업을 병렬적으로 하게 되면 브랜치를 만들어야 한다.

말 그대로 나뭇가지처럼 큰 줄기(main)에서 작은 줄기(feature)들을 뽑아서 작업을 하는 것이다.

 

이때 규칙이 있는데. main브랜치에는 직접 커밋을 하지 않는다.

모든 기능개발을 시작하기 전에는 main을 기준으로 새로운 브랜치를 만든다.

브랜치 이름은 feature/{기능} 으로 하고 한 명만 커밋을 올린다.

feature/{기능} 브랜치에서 작업이 끝나면 main에 이것을 합친다.

 

기존에 main브랜치에서 두명이 병렬적으로 작업을 한다.

A가 feature/a 브랜치를 만들어서 작업 후 커밋하고 원격저장소에 푸시했다.(최종 커밋: 커밋 4)

B가 feature/b 브랜치를 만들어서 작업 후 커밋하고 원격저장소에 푸시했다.(최종 커밋: 커밋 5)

feature/a feature/b main에 있는 버전이 모두 다르다. 

이제 작업을 완료했으니 feature/a 와 feature/b를 다시 main으로 merge 해야 한다.

main브랜치로 이동해서 feature/a를 병합한다.

커밋 4는 단순히 커밋 2를 수정한 상태이기 때문에 fast-forward 방식으로 병합된다.

소스트리에서 fast-forward가 가능해도 새 커밋으로 생성을 하게 할지 선택할 수 있는데, 이것은 선택이다.

책에는 브랜치가 물리적인 물길처럼 나눠져 있는 게 아니라 단순한 포인터라서 이런 방식이 가능하다고 아주 자세히 설명이 나와있다.

이제는 main브랜치도 커밋 4를 가리키게 되었다.

이제 feature/b도 작업이 완료되었으니 main에 병합해 보자.

이번에는 상황이 다르다. 커밋 2에서 분기가 되었는데 병합하려고 상태를 보니 커밋 4가 되어있다.

이런 경우는 fast-forward가 아니라 merge commit(병합커밋)이 된다.

상태를 비교해서 합치면서 변경사항을 합치면서 커밋을 만들게 되는데, 어떤 브랜치에서 합칠지 선택해야 한다.

나는 feature/b에서 먼저 main브랜치를 합쳐서 살펴보고 싶다. 왜냐하면 A가 어떤 코드를 수정했는지 모르기 때문에

충돌이 있을 수 있기 때문이다. 이 충돌을 먼저 내 작업브랜치에서 해결하고 main에 병합시키고 싶다.

feature/b로 이동해서 main을 병합한다. 이때 병합커밋이 feature/b 브랜치에 새로 생긴다.

만약 이때 충돌이 있다면 수정할 수 있다.

충돌을 수정하고 나면 원격에도 반영하고 main에 다시 올려준다. 이제 main은 배포 가능한 상태가 되었다.