Chap.3 여러 명이 함께 Git으로 협업하기
01_GitHub Repository에서 협업하기
1) 두 명이 동시에 버전 관리를 해야 한다면?
두 명이 동시에 버전 관리를 할 때에도 서로의 작업물에 의존하지 않고 내가 원할 때 코드를 올리고, 또 내가 원할 떄 협업자의 코드와 합칠 수 있다.
2) Git이 Commit을 관리하는 방식: 줄줄이 기차
- 한 명이 작업한다면 시간순대로 Commit을 쌓아가면 된다.
- 두 명이 작업한다면 Commit3 기준으로 각기 다른 수정 버전으로 나뉘기 시작한다.
- 이렇게 특정 기준 시점에서 가지처럼 나뉘어 작업할 수 있는 기능을 브랜치(Branch)라고 한다.
- 새로운 가지로 Commit을 만들려면 반드시 Branch를 먼저 만들어야 한다.
- 만들지 않고 뒤늦게 Push한 Commit은 "최신 코드에 Push해라" 라고 오류가 발생한다.
3) Branch, 정체를 밝혀라!
- Main Branch에서 Commit을 하나 만들면 Main Branch 꼬리표가 Commit1에 달린다.
- 여기서 Commit2를 만들면 Main Branch 꼬리표 최신인 Commit2에 달린다.
Main Branch가 Commit을 '가리킨다' 라고 하는 이유는 Branch가 물리적인 길이 존재하는 것이 아니고 단순한 Pointer이기 때문.
- Commit3 상태에서 고양이 Branch를 만든다면 Main Branch와 동일하게 Commit3를 가리킬 것이다.
- 만약 Branch가 물리적이고 독립적인 길이었다면 고양이와 Main Branch마다 Commit3를 새로 올렸을 것이다.
- 하지만 Branch는 Pointer이므로 그저 Commit을 가리키는 것만으로도 분기를 만들 수 있다는 장점이 존재.
- 원래 분기를 만드려면 프로젝트를 통째로 복사하기에 SubVersion과 같은 버전 관리 툴은 무겁고 시간이 오래 걸린다.
- 고양이 Branch에 Commit4를 추가하면 Main Branch보다 Commit 하나만큼 앞서게 된다.
- Main Branch로 이동해서 Commit5를 추가하면 고양이 Branch와 버전이 갈라지게 된다.
- HEAD라는 특수한 Pointer를 통해 Branch 사이를 마음대로 넘나들 수 있다.
- 그림에서는 HEAD가 Commit5 Main Branch를 가리키고 있기에 Commit5의 상태를 보여준다.
- HEAD가 Commit4 고양이 Branch를 기라키게 하면 Commit4의 상태를 보여준다.
- Branch의 최신 Commit이 아닌 과거 Commit으로도 HEAD를 이동시킬 수 있다.
- 다만, 이 경우에는 Branch의 Pointer와 HEAD Pointer가 떨어져 있게에 '분리된 HEAD(Detached HEAD)'상태가 됩니다.
02_Branch 만들고, 이동하기
1) Branch: 새 Branch 만들기, Checkout : Branch 이동하기
협업을 위해 Branch를 어떻게 사용해야 할까?
- 협업자는 Commit을 올릴 Branch를 각각 만든다.
- 자신이 만든 Branch로 이동(Checkout)
- Branch에 Commit
- 개발 완료 후 Branch Merge
- 보통 하나의 개발 Branch에는 한 사람만 작업해서 올려야 버전이 꼬이지 않는다.
- 따라서 협업 장소인 원격 Repository에서는 미리 Branch Convention을 정한다.
- Branch를 새로 만들면 현재 Checkout된 Branch가 가리키는 Commit을 기준으로 갈라진다.
- Checkout = Branch를 이동하는 명령어
03_Merge: Branch + Branch
1) Merge는 무엇인가요?
Merge = 두 버전의 합집합을 구하는 것.
1. Merge Commit : 새로운 Commit 생성
2. Fast-Foward : State를 새로 만들 필요 없이 '모자 쓴 문어' Commit으로 State 변경하면 됨
3. Conflict : 부분 확인 후 무엇을 남길지 수동으로 선택하면 됨
2) 두 개의 Branch를 Merge하는 과정
각각 개발된 두 개의 Branch를 Main Branch에 Merge해야 하는 상황.
- feature/detail-page Branch가 가리키는 Commit4는 Base가 Commit2이기 때문에 Merge하게 되면 Fast-Foward된다.
- Merge 후, Main Branch도 Commit4를 가리키게 되었다.
- feature/detail-page Branch의 모든 내용이 Main Branch에 반영되었으니 feature/detail-page Branch는 삭제해도 된다.
- Commit4와 Commit5는 Commit2를 Base로 한 각기 다른 Commit이다.
- 이 상황은 Merge Commit이다.
- 새로운 Merged Commit은 Main Branch에서 Commit해도 되고 feature/cart Branch에서 Commit해도 된다.
어떤 것을 Base로 Merge하느냐
- Main Branch를 Base로 Merge한다 = Merge한 결과물을 Main Branch에 반영하겠다 = feature/cart Branch에는 반영이 안된다.
- feature/cart Branch를 Base로 Merge한다 = Merge한 결과물을 feature/cart Branch에 반영하겠다 = Main Branch에는 반영이 안된다.
3) Fast-Foward Merge with Sourcetree
04_Conflict : 같은 코드를 고쳤다
Merged Commit 만들기
각각 개발된 두 개의 Branch를 Main Branch에 Merge해야 하는 상황.
하지만 feature/cart Branch를 Base로 Merge해보기.
- Commit3와 Commit4는 Commit1을 Base로 한 각기 다른 Branch에 있어서 Merged Commit을 만들면서 코드를 Merge해야 한다, 따라서 두 개의 Commit이 같은 코드를 수정했다면 Merged Commit을 만들다가 Comflict가 될 수도 있다.
- 해결법은 같이 사용하는 Main Branch에 바로 Merge하지 않고 개인이 사용하는 feature/cart Branch에서 먼저 Merge해보고 Conflict가 있는 지 확인한다.
- Merged Commit이 문제 없는 것을 확인한 후 Merged Commit을 Main Branch에 반영
- Main Branch에서 바로 Merge해서 Conflict가 발생해도 Main Branch에서 해결하면 된다, 단지 다른 사람이 불편해지는 상황을 방지하기 위해 본인의 Branch에서 Debuggig을 하는 것.
05_Pull Request : The One of Methods for Merge Branches
1) Pull Request는 협력자에게 Branch Merge를 요청하는 것.
06_Realease : Develop's Done, Let's Realease
1) Program의 Version이란?
Program을 Realease하거나 Upgrade할 때, 만든 회사에서는 Version을 명시한다.
Git에서 말하는 Version도 비슷한 맥락으로 의미있는 특정 시점의 맥락을 말하는 것.
Version을 올리는 것은 크게 Major Upgrade와 Minor Upgrade로 나뉜다.
사용자들이 크게 느낄 변화를 적용했을 때 보통 Major Version을 올리고(v2.x -> v3.x),
작은 변화 등이 생겼을 때는 Minor Version을 올린다(v.2.3 -> v.2.4).
Version '2.3.0'에서 세 번째 Version은 Maintenance Version으로, 버그나 유지 보수 등 작은 수정이 들어갔을 때 바꾼다.
2) Tag : 특정 Commit에 Post-it 붙이기
Tag는 특정 Commit에 표시하고 싶은 것을 기록하는 것. ex) v.1.0.0
GUI에서 Main Label 표시와 같이 'v.1.0.0'이라고 Label이 붙어있는 이유는 Branch와 같이 Commit을 가리키는 Pointer이기 때문.
Tag도 Push해야 GitHub Repository에서 볼 수 있다.
