[Git]02 - 협업 / Branch / HEAD / Conflict / Pull Request

개념 정리

브랜치 특정 기준에서 줄기를 나누어 작업할 수 있는 기능
체크아웃 브랜치를 이동하는 명령어. 새 브랜치를 체크아웃 체크박스를 선택하면 브랜치를 만듦과 동시에 그 브랜치로 이동하게 된다. 체크를 해제하고 브랜치를 생성하면 HEAD는 여전히 master를 가리킨다.
병합merge 두 버전의 합집합을 구하는 것.

---

여러 사람이 동시에 버전 관리를 해야한다면 ?

• 서로의 작업물에 의존하지 않고 내가 원할 때 코드를 올리고, 또 내가 원할 때 협업자의 코드와 합칠 수 있다.
• 특정 기준에서 줄기를 나누어 작업할 수 있는 기능을 브랜치라고 한다.
• 새로운 가지로 커밋을 만들려면 반드시 브랜치를 먼저 만들어야한다.
• 여러 작업자가 한 커밋을 기준으로 커밋을 만드려고 한다면 오류가 난다.
  • 먼저 커밋한 사람은 정상적으로 올라가고, 늦게 커밋한 사람은 ‘최신 코드에 푸시하라’라는 오류가 난다.

브랜치에 커밋을 올린다(X) 가리킨다(O)

• 나뭇가지처럼 물리적으로 ‘길’이 존재해서 그 길에 올리는 것이 아니라 단순한 ‘포인터’다.
• 커밋1, 커밋2, 커밋3을 만들었다고 가정할 때 master 브랜치의 포인터가 최신 커밋을 가리키고, 커밋4를 올리면 master 브랜치는 커밋4를 가리킨다.
• 분기를 만드려면 프로젝트를 통째로 복사해서 무겁고 시간이 많이 걸리는 svn과 달리 git은 가볍고 빠르다.

브랜치 사이를 넘나들기 HEAD

• master브랜치와 고양이브랜치를 넘나드는 방법으로 HEAD라는 특수한 포인터가 있다.
• HEAD는 브랜치 혹은 커밋을 가리키는 포인터인데, HEAD를 이용해서 브랜치 사이를 마음대로 넘나들 수 있다.
• HEAD는 브랜치의 최신 커밋이 아닌 과거 커밋으로도 이동 시킬 수 있다. 이런 경우에는 master브랜치의 포인터와 HEAD가 떨어져있기에 분리된 HEAD (Detached HEAD)상태가 된다.

새 브랜치 만들기

• 보통 하나의 개발 브랜치에는 한 사람만 작업해서 올리는 것이 바람직하다. 그래야 버전이 꼬일 걱정이 없다. 그렇기 때문에 여러 사람이 작업하는 원격저장소에는 미리 브랜치 규칙을 정하는 것이 일반적이다.
• 예시로 간단한 4가지 규칙
  1. master브랜치에는 직접 커밋을 올리지 않는다.
  2. 기능 개발 하기전에 브랜치를 기준으로 새로운 브랜치를 만든다.
  3. 브랜치 이름은 feature/기능이름 형식으로 하고 한 명만 커밋을 올린다.
  4. feature/기능이름 브랜치에서 기능 개발이 끝나면 master브랜치에 이를 합친다.

브랜치 이동하기

• 병렬로 커밋을 올리기 위해서는 브랜치를 새로 만들어야한다.
• master 브랜치로 돌아가서 새로운 브랜치를 생성한다.
  • ! master브랜치로 이동하지 않고 feature/detail-page 에 남아서 브랜치를 만들면 수정본까지 모두 반영이 되는 불상사가 생긴다.
  • ! 브랜치를 만들때는 base 브랜치를 잘 설정해야한다.

병합 Merge

• 병합 커밋 Merge Commit : 서로 다른 내용이 커밋 되었을때 합체
• 빨리감기 Fast-forward : 기존커밋에 추가된 내용이 있을때
• 충돌 Conflict : 같은 부분을 수정했을 때

• 병합 Merge 브랜치와 브랜치를 합치는 명령어를 말한다.
• 브랜치를 기준으로 병합한다의 의미?
  • A브랜치와 B브랜치를 합쳤을때 만들어진 AB 브랜치를 A브랜치에 올릴지, B브랜치에 올릴지 정하는것. 만약 A브랜치에 올린다면 AB브랜치가 A브랜치에만 반영되고 B브랜치는 B인 상태 그대로.

충돌 Conflict

• 마스터 브랜치와 A 브랜치가 있다고 가정한다.
• 병합중에 코드가 깨질 수 있으므로 전용 A브랜치에 마스터 브랜치를 땡겨와서 A브랜치에 병합한다 (master→ A브랜치)
• 문제가 없는지 확인한다.
• 병합커밋을 master 브랜치에 반영한다
• ! 물론 master 브랜치에 바로 병합해도 상관은 없다. 충돌이 나더라도 master브랜치에서 해결하면 된다. 하지만 다른 사람이 불편해지는 상황을 방지하기 위해 개인 A 브랜치에서 먼저 병합하는 것이 좋다.
• 충돌 수정하기

<<<<<<< HEAD
어쩌구 저쩌구  // (1)새로 추가한 코드
=======
저쩌구 어쩌구  // (2)다른 누군가가 수정한 코드
>>>>>>> master

• 충돌을 해결한 뒤 master 브랜치에도 반영한다.
  • 충돌이 난 코드 위에서 아래 버튼을 누를 수 있다.
    • Accept Current Change 위의 코드만 남기기
    • Accept Incoming Change 아래의 코드만 남기기
    • Accept Both Change 위아래 모두의 코드가 남는다.
    • Compare Changes 비교하기 편한 view로 전환한다.

예의바르게 브랜치 합치기 Pull Request

• 코드 충돌만 해결했다고 master 브랜치에 병합해서는 안된다.
• master 브랜치에 완벽한 코드만 두기로 했다면, 이 브랜치에서 무엇을 바꾸었는지 협력자Collaborators가 확인할 수 있는 과정을 거쳐야한다. 이때 Pull Requset를 사용한다.
• A브랜치로 B브랜치를 병합해도 되겠니? 수정사항은 다음과 같아 ! 라는의미
• 초록색 Compare & Pull Request 버튼은 최근에 푸시한 브랜치가 있을때만 보여진다. 다른 브랜치로 풀 리퀘스트를 보내고 싶거나, 직접 설정을 변경하고 싶다면 그아래줄 좌측의 New Pull Request 버튼을 클릭하면 된다.
• Pull Request 를 눌렀을때 먼저 설정해야 할 것은 베이스base브랜치와 비교Copmare브랜치이다. 병합 결과물이 올라갈 기준이 되는 브랜치가 base브랜치, 현재 기준 브랜치의 비교대상이 되는 브랜치가 비교Compare 브랜치.