[Git] Branch(브랜치) vs Fork(포크) (with. Pull Request)

---

Pull Request(풀 리퀘스트)로 보는 차이

---

Pull Request?

• 원본 저장소에 병합을 요청하는 것(권한이 없어도 가능)

클릭 순서

1. base:master : 병합된 커밋이 들어갈 브랜치를 정하는 선택박스
2. compare:JP-test : 병합의 대상, 즉 base 브랜치에 반영시키고 싶은 브랜치
3. Able to merge : 두 브랜치가 충돌 없이 병합될 수 있다는 뜻
   1. 만약 충돌이 나면 빨간색으로 Conflict 표시
      
      
4. 풀 리퀘스트 제목 : 동료 개발자가 한눈에 이해하기 쉬운 제목을 적어야 함
5. 풀 리퀘스트 내용 : 동료 개발자가 코드를 이해하는데 도움이 되는 설명
   1. 스크린숏 첨부 및 테스트 방법 서술
      
      
6. Reviewers: 저장소에 협력자가 여러 명이라면 해당 요청을 받는 사람을 지정 가능
   1. 보통 기능 연관자 지정
      
      
7. Assignees: 해당 풀 리퀘스트를 담당하는 동료를 적음. 보통 자기 자신
8. Labels : 해당 풀 리퀘스트에 대한 라벨을 달아줌.
   1. ex) [버그], [리뷰 필요], [프런트엔드], [백엔드]

 

---

Branch

 

• Branch를 나누어 기능 작업 후 Pull Request → 관리자 승인
• 원본저장소 안에서 분기를 나누어 작업 → 평행세계 같은 느낌?
• 하나의 원본저장소 안에서 커밋을 나눌 수 있다
  → 커밋 로그를 쉽게 확인할 수 있고, 원본 저장소의 내용을 쉽게 최신화 가능
  
  
• 소수의 인원들끼리 개발할 때 적합한 방식
  → 인원이 많아지면 커밋로그가 많아지기 때문에 혼잡해져 굉장히 관리하기 불편해짐

 

---

Fork

• 원본저장소를 통째로 복사해서 내 독립된 저장소로 복사해 오는 것(원격저장소)
  → 해당 시점에서의 원본저장소와 같으나, 원본저장소에 영향을 끼치지 않는 복제본(평행우주)
  
  
• 원본저장소에 영향을 끼치지 않기 때문에 원격저장소에서 마음껏 코드 수정 가능
• 원본저장소와 분리되어 있기 때문에, 원본 저장소의 커밋이 추가되지 않음
  → 따로 주소를 추가하거나 일일이 확인해야 함.
  
  
• 개발인원이 많을 때나 Git Hub contributor 시스템이 해당 방식
  → 원본 저장소를 fork 하고 기능추가 후 pull request → 관리자가 승인하면 기여자가 됨