[팀 개발을 위한 Git, GitHub 시작하기] - Ch 3. 여러 명이 함께 Git으로 협업하기

원격 저장소에서 협업하기

두 명이 동시에 버전 관리를 할 때에도 서로의 작업물에 의존하지 않고 내가 원할 때 코드를 올리고, 또 내가 원할 때 협업자의 코드와 합칠 수 있다.

 

커밋은 줄줄이 기차처럼 연결되어 있다. 새로 만든 커밋은 기존 커밋 다음에 시간순으로 쌓인다.

두 명이 협업한다면 새로운 두 커밋 모두 기준 커밋과 연결되어야 하기 때문에, 두 갈래로 나뉘게 된다.

 

브랜치

특정한 기준 시점에서 줄기를 나누어 작업할 수 있는 기능

새로운 가지로 커밋을 만들려면 반드시 브랜치를 먼저 만들어야 한다.

브랜치는 나뭇가지처럼 물리적인 길이 존재해서 그 길에 커밋을 올리는 게 아니라, 단순한 포인터이다.

순서대로 커밋 1, 커밋 2, 커밋 3을 만들었으면, 새로 커밋할 대마다 main 브랜치의 포인터가 최신 커밋을 가리키게 된다.

 

HEAD

브랜치 혹은 커밋을 가리키는 포인터이다. HEAD를 이용해서 브랜치 사이를 마음대로 넘나들 수 있다. 일종의 타임머신 역할이다.

main 브랜치의 포인터와 HEAD가 떨어져 있으면 분리된 HEAD(Detached HEAD) 상태가 된다.

 

2. 브랜치 만들고 이동하기

• main 브랜치에는 직접 커밋을 올리지 않는다.
• 기능 개발을 하기 전에 main 브랜치를 기준으로 새로운 브랜치를 만든다.
• 이 브랜치 이름은 feature/기능이름 형식으로 하고 한 명만 커밋을 올린다.
• feature/기능이름 브랜치에서 기능 개발이 끝나면 main 브랜치에 이를 합친다.

 

새 브랜치를 생성한다.

 

 

새 파일을 추가한 뒤, 커밋한다.

 

 

 

기존에 만들었던 feature-list.md에 텍스트를 추가하고, 커밋한다.

 

 

원격 저장소에도 브랜치가 잘 올라와 있다.

체크아웃

브랜치를 이동하는 명령

 

브랜치를 더블클릭하거나, 브랜치 이름을 마우스 오른쪽 버튼으로 클릭하고 [체크아웃]을 선택한다.

 

메인 브랜치로 체크아웃한다.

 

 

새 브랜치를 생성한 뒤, 체크아웃 한다.

 

 

직전에 텍스트 추가한 걸 무시하고 새로 4라인을 추가한 뒤, 파일을 하나 더 추가한다.

 

 

커밋, 푸시한다.

 

 

병합 : 브랜치와 브랜치 합치기

각각 병렬로 작업한 브랜치를 합치는 과정

병합(merge)

두 버전의 합집합을 구하는 것

빨리 감기(fast-forward)

현재 브랜치에서 대상 브랜치를 병합할 때 대상 브랜치의 커밋이 현재 브랜치보다 앞서 있는 경우 현재 브랜치의 HEAD 포인터를 대상 브랜치로 이동(빨리감기)하는 것

 

 

main으로 체크아웃한다.

 

 

병합하려는 커밋에 대고 [병합] 선택한다.

 

 

main[2] → 2개의 커밋이 로컬 저장소에만 이루어졌고 원격 저장소(origin)에는 올라가지 않았다.

분홍색 [main] 브랜치가 파란색 [origin/main] 브랜치보다 2 커밋 앞서 있다.

push해서 원격 저장소에 반영한다.

 

브랜치를 기준으로 병합한다는 것의 의미?
A, B 브랜치 두 개를 합쳤을 때 만들어진 AB 브랜치를 A 브랜치에 올릴 지, B 브랜치에 올릴 지 정하는 것이다.

 

충돌(Conflict)

 

파일에서 동일한 위치에 두 명 이상이 서로 다르게 수정했을 때 나타나는 충돌

 

두 브랜치의 코드가 모드 [main] 브랜치에 병합하여 두 브랜치의 코드가 모두 [main] 브랜치에 반영된 상태로 만들어 본다.

feature 브랜치 기준으로 병합해 본다.

혹시 모르니 나만 쓰는 feature/cart 브랜치에 먼저 병합해 보고 [main] 브랜치로 병합한다.

 

 

feature/cart 브랜치로 체크아웃한다.

 

 

main 브랜치의 최신 커밋에서 병합한다.

이 때, 충돌 메시지가 발생하게 된다.

 

 

충돌이 난 파일을 들어가 보면, ===를 기준으로 위는 베이스 브랜치인 feature/cart 브랜치의 코드가, 그 아래는 병합의 대상인 [main] 브랜치의 코드가 나타난다.

충돌난 코드를 수정한다.

 

 

커밋을 하게 되면 입력란에 자동으로 텍스트가 나오게 된다.

Merge branch 'main' into feature/cart

# Conflicts:
#	feature-list.md

 

main 브랜치를 [feature/cart] 브랜치에 병합하려고 하는데, feature-list.md 에서 충돌이 났다는 내용이다.

 

 

feature/cart 브랜치의 ‘장바구니 담기 기능’ 커밋과 main 브랜치의 ‘기능 명세 3번에 추가’ 커밋이 합쳐진 병합 커밋이 생성되어 feature/cart 브랜치에 올라와 있다.

 

 

원격 저장소에도 반영한다.

이 커밋을 main 브랜치에 반영한다.

 

 

main 브랜치로 체크아웃 한 뒤 병합한다.

 

 

main 브랜치의 포인터가 최신 커밋으로 왔다.

 

 

원격 저장소에도 반영한다.

 

 

원격 저장소에 올라온 브랜치들을 확인할 수 있다.

 

풀 리퀘스트 : 브랜치를 합치는 예의바른 방법

풀 리퀘스트(pull request)

협력자에게 브랜치 병합을 요청하는 메시지를 보내는 것

Github의 풀 리퀘스트 버튼은 자동으로 이 메시지를 만들어 준다.

 

고양이와 문어는 main 브랜치에는 직접 올리지 않고, 각자 feature/ 브랜치를 만들어 개발이 완료되면 병합을 하기로 했다.

그리고 개발이 완료되면 무조건 풀 리퀘스트를 보내고 서로가 [승인]을 했을 때 병합을 하기로 했다.

 

댓글 기능을 만들고 이 규칙을 풀 리퀘스트 한다.

 

 

feature/comment 브랜치를 새로 생성한 뒤, comment.md 를 만든다.

 

 

댓글 기능을 추가한 뒤 커밋, 푸쉬한다.

 

 

원격 저장소에 풀 리퀘스트가 올라와 있다.

이 브랜치에 코드를 업데이트 한 것을 협력자에게 풀 리퀘스트를 보낼지에 대한 여부를 묻는다.

 

 

 

베이스 브랜치와 비교 브랜치를 설정한다.

Reviewer를 설정하여 협력자에게 풀 리퀘스트를 보낼 수 있다.

 

 

내 브랜치에서 개발한 내용에 대한 제목과 설명을 입력한다.

 

 

iTshirt 원격 저장소의 협력자(문어)가 이 풀 리퀘스트를 확인하고 새롭게 추가된 코드를 검토할 수 있다.

코드의 라인마다 댓글을 달 수 있어서 해당 코드가 왜 고쳐졌는지, 혹은 어떻게 개선할 수 있는지 풀 리퀘스트 내부에서 토론을 진행할 수 있다.

문어는 이 풀 리퀘스트를 Accept 하거나, Request Change(수정 요청) 하거나, Merge pull request(병합)할 수 있다.

 

코드를 확인해 보고 이상이 없으면 [Merge pull request]를 수정한다.

 

 

닫힌 pull request를 확인할 수 있다.

 

 

원격 저장소의 origin/main 브랜치는 옛날 커밋을 가리키고 있다.

 

 

[패치] 버튼을 클릭하여 Github의 새로운 이력을 업데이트 한다(소스코드는 10분에 한 번씩 자동으로 패치된다).

 

 

origin/main이 새롭게 만들어진 병합 커밋인 ‘Merge pull request #1’을 가리키고 있다.

 

 

릴리즈 : 개발이 완료되었습니다.

프로그램의 버전(version)

메이저 업그레이드

사용자들이 크게 느낄 변화를 적용했을 때 주로 올린다.( v2.0 → v3.0)

 

마이너 업그레이드

작은 변화가 생겼을 땐 마이너 버전을 올린다.(v2.3 → v2.4)

 

태그: 특정 커밋에 포스트잇 붙이기

릴리즈

프로그램을 출시하는 것

 

 

Merge pull request #1 커밋에 v1.0.0 이라는 태그를 단다.

 

 

태그는 브랜치와 마찬가지로 푸시해야 원격 저장소에서도 볼 수 있다.

 

 

zip 아이콘을 클릭하면 해당 태그가 가리키는 버전을 압축 파일로 다운로드할 수 있다.