Github 사용해보기 2

이전 Github 관련 글

• https://syrbear.tistory.com/21

---

결국 중요한 것은 직접해보는 것, 이 글은 직접할때 필요한 내용을 참조하기 위해 작성

코드 리뷰

• 상대방의 코드를 검토하고 피드백하는 과정
  코드 리뷰의 장점

1. 코드를 더 신경써서 짜게 됨
2. 새로운 코드를 이해하고 분석하는 능력이 길러짐
3. 특정 사고에 갇히지 않도록 도움을 받을 수 있음
4. 버그나 중복 코드의 사용을 알 수 있음

=> 소프트웨어(코드)의 품질 향상

코드 리뷰 어떻게 해야할까

• 코드 작성자 : 코드 구조, 설계 방식, 작성한 이유 등을 자세히 설명
• 코드 리뷰어 : 규칙을 잘 지켰는지, 버그의 유무, 개선 사항 등을 확인 -> 궁금한 점은 질물, 배울만한 점 등은 칭찬

코드 리뷰 방법 (과정)

1. PR한 코드를 로컬에 받아와서 상세히 확인
2. PR(Pull Request)에 들어가서 원하는 PR을 선택 후 File changed를 클릭해서 코드를 확인
3. 라인번호 옆의 +를 통해서 리뷰를 남길 수 있음, 여러줄을 선택하면 여러줄에 대한 리뷰도 가능
4. suggestion으로 코드도 제안이 가능한데 제안 코드는 바로 적용가능하다 - 커밋으로 남음(소유는 공동)
5. Add single comment 로 리뷰를 남길경우 한개의 리뷰만 남겨지고 Start Review로 남기면 여러개를 한번에 등록이 가능한데 이때는 Pending 상태로 넘어감(이후 Finish Review -> Submit을 통해 들록 가능)

• 리뷰의 종류 : comment(단순리뷰), approve(승인O - merge가능), request changes(승인X - 수정 필요)

Branch

• 사용방식 : 브랜치로 소스를 복제 -> 각각 작업 -> 하나로 합침 -> 전체를 하나로 합침
• master, main : 일반적으로 가장 기본적인 초치초의 브랜치
• check out : 특정 브랜치로 작업 환경을 바꾸는것 (ex. git checkout branch1, git checkout main)
• 상세한 작동 방식
  1. Project1에서 A브랜치를 생성 -> 작업진행 -> 커밋(본인만 알 수 있음) -> 푸쉬(이때 다른 사람도 패치로 변경사항을 확인가능)
  2. Project2에서 A브랜치로 체크아웃 -> 패치(변경사항확인) -> (변경사항이 있음)풀(내려받음)
  3. Project2에서 B브랜치를 생성 -> 작업진행 -> A랑 merge를 하던가 main에 PR (A에서도 가능)

Pull Request (PR)

• merge 하기 전에 진행하는 작업
• Reviewers : PR을 리뷰해 줄 팀원 지정
• Assignees : PR 올린 작업의 담당자
• base : 병합할 브랜치 (남는 브랜치)
• compare : 병합될 브랜치 (합쳐지고 없어지는 브랜치)
• Able to merge : PR이 승인이 되면 merge가 자동으로 진행 되는지 (충돌여부)
• Approve : PR의 통과 동의(승인?)한 수 - 설정에서 몇개 이상일때만 진행할지 설정가능

Merge

• PR이 통과 되면 지정한 base에 compare을 병합시킴 - 충돌이 발생할 수 있음
• PR에서 통과 후 merge 방식
  1. Crete a merge commit 방식 : main 브랜치에 병합, 브랜치의 커밋 기록들이 직관적으로 병합 (일반적인 git merge 'base'와 같음)
  2. Squash and merge 방식 : PR의 commit을 한 개 추려서 main 브랜치에 병합, PR 제목으로 된 1개의 로그로 main에 병합
  3. Rebase and merge : PR의 커밋 로그들이 main에 재정렬 되어 병합, 마치 base에서 작업한 것 처럼 로그가 남음