개발 협업

PR(Pull Request)

다른 GitHub 사용자들에게 자신의 작업한 내용을 검토하고 머지해 달라고 요청하는 GitHub의 기능

PR 하는 법

1. 작업할 프로젝트 생성하기
2. 프로젝트 clone 하기

git clone https://github.com/<username>/<repository-name>.git

3. 새로운 브랜치 생성하기

git checkout -b my-first-branch

4. 변경 사항 푸시하기

git push origin

5. PR 생성하기
   Create pull request를 클릭

Pull Request의 상태

Open

Open 상태의 PR은 아직 검토가 완료되지 않았거나, 추가적인 작업이 필요한 상태이다.
이 상태에서는 더 많은 커밋을 추가하거나 토론을 진행하며 수정을 요철할 수 있다.

Merged

Merged 상태의 PR은 소스 코드의 기본 브랜치로 병합된 상태
Pull Request 화면에서 Merge 버튼을 누르게 되면 해당 상태로 변경되게 된다.
이는 해당 PR의 변경 사항이 승인되었고, 코드에 통합되었다는 것을 의미하고 이후 추가적인 변경이나 커밋을 추가할 수 없다.

Closed

거부되었거나, 더 이상 유효하지 않은 PR
Closed 상태로 전환된 후에도 브랜치가 존재한다면 다시 Open 상태로 되돌릴 수 있다.

PR Merge

깃허브에서는 두 개의 브랜치를 머지하는 총 3가지의 방법이 있다.

1. merge commit을 만들며 합치기
   두 브랜치의 변경 사항을 모두 유지하면서 병합
   각 브랜치의 변경 사항이 과거의 커밋으로 보존되고, 새로운 커밋이 추가되어 최종 병합이 완료된다.
   
   장점과 단점
   이 방식은 브랜치의 히스토리를 모두 유지하면서 변경 사항을 병합할 수 있다는 장점이 있다. 이를 통해 프로젝트의 진행 상황을 명확하게 이해하고 추적할 수 있고, 모든 커밋들의 커밋 아이디가 바뀌는 경우가 없기 때문에 다음에 다룰 squash와 rebase 방식에 비해서 비교적 사용이 쉽다.
   단점은 커밋 히스토리가 복잡해질 수 있다는 것이다. 다양한 브랜치에서 여러 작업이 이루어지면 커밋 로그가 빠르게 복잡해질 수 있다. 팀이 커지면 커질수록 이 복잡성은 빠르게 증가하게 된다.

2. Squash and merge 하기
   브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방식입니다. 이 방식은 각각의 커밋에서 발생한 모든 변경 사항을 병합 후에 하나의 새로운 커밋을 생성
   
   장점과 단점
   이 방식은 커밋 히스토리를 간단하게 유지할 수 있단 장점이 있다. 이로 인해 각 커밋이 특정 Pull Request를 대변하게 되고, 그 의미를 이해하기 쉽게 다. 다시 말해서 커밋 하나하나가 완성된 기능을 의미하게 됩니다. PR에서 발생한 자잘한 문제들을 숨기고, 그 PR에서 가장 중요하고 필요했던 내용들만 압축하여 담게 된다.
   단점은 작업의 상세한 이력을 잃게 된다는 것이다. 각 커밋에 대한 개별적인 맥락이나 작업자의 정보 등이 포함되지 않기 때문에 추후 문제 해결이 어려울 수 있다. 또한 기존의 작업 커밋의 아이디들이 하나로 합쳐지며 사라지고 새로운 커밋 아이디가 생성되기 때문에 여러명이서 해당 브랜치를 기반으로 작업을 수행하고 있었다면 병합이 이뤄지는 경우 복잡한 문제를 야기할 수 있다.
   GitHub에는 해당 커밋 기록들이 모두 남아있기 때문에 squash 방식을 사용한다고 해서 모든 커밋 내역이 날아가는 것은 아니다. Pull Request를 검색해서 해당 작업의 커밋 히스토리를 확인 할 수 있다.

3. Rebase and merge 하기
   'Rebase and Merge'는 현재 브랜치를 target 브랜치에 재위치(rebase)시킨 후 병합하는 방식이다. 이는 target 브랜치의 커밋 위로 현재 브랜치의 모든 커밋을 옮겨 놓는 것과 같다. 이렇게 되면 커밋 히스토리는 선형적으로 유지된다.
   
   장점과 단점
   이 방법은 깨끗하고 선형적인 커밋 히스토리를 만들어 준다는 장점이 있다. 이로 인해 히스토리 파악 및 코드의 변화 이해가 더욱 쉬워질 수 있다.
   단점은 관련된 커밋의 ID들이 모두 바뀌게 되어 혼란을 초래할 수 있다는 점이다. 이는 특히 브랜치가 크게 분기된 경우에는 복잡하고 어려울 수 있다. 여러 개발자가 동시에 작업을 수행한 경우에는 rebase 방식이 복잡한 충돌을 일으킬 수 있다.
   추가로, PR별로 다른 기능으로 나뉘어 있던 작업 이력이, 하나의 선형적인 히스토리로 합쳐지는 단점이 있다. -> 특정 기능이 어디서부터 어디까지의 커밋으로 구현되었는지 알기 어려워진다.

결과는 3가지 중 어느 것으로 하더라도 달라지지 않는다.

Fork

이미 존재하는 원격 Git repository를 사용자의 계정으로 복사하는 기능

fork 하는 방법

1. GitHub에서 원하는 프로젝트의 페이지로 이동
2. 우측 상단에 있는 'Fork' 버튼을 클릭하여 해당 프로젝트를 자신의 계정으로 Fork 한다.
3. Fork 된 저장소로 이동하고, 변경 사항을 반영할 브랜치를 생성한다.
4. 변경 사항을 커밋하고 푸시한다.
5. GitHub 웹 사이트에서 Fork 된 저장소로 이동한 후, 'New pull request' 버튼을 클릭한다.
6. 변경 사항을 반영할 원본 저장소와 브랜치를 선택한다.
7. Pull Request를 작성하고 제출

PR에서 충돌이 발생하는 경우

• Resolve conflicts 버튼을 눌러 해결하기

1. 현재 브랜치의 내용을 선택하는 것 (main, print("codeit")를 사용)
   Accept Current
2. 가져오는 브랜치의 내용을 선택하는 것 (test/branch1 print("hello")를 사용)
   Accept Incomming
3. 두 가지 모두를 선택하는 것
   Accept Both
4. 두 코드를 보고 직접 수정하는 것
   <<< === >>> 를 삭제 후 직접 코드를 수정

• 로컬에서 충돌 해결하기

해당하는 브랜치로 이동

git checkout test/branch1

코드 머지

git merge main

같은 방식으로 로컬에서 충돌 해결 후 git add, git commit, git push

PR 충돌을 최소화 하는 방법

• 최신 코드 유지
  주기적으로 원본 브랜치의 최신 변경 이력을 main 브랜치로 가져오기(git merge feat)
• 작은 Pull Request 만들기
• 파일을 작게 만들기
• 동료들과 많은 커뮤니케이션 수행하기

좋은 PR이란

• Communication
  무엇을 변경하려고 하는지, 왜 그렇게 하려고 하는지, 그리고 그것이 어떤 영향을 미칠 것인지를 명확히 전달
• Pull Request를 작게 만들기

1. 하나의 PR은 하나의 문제를 해결해야 한다.
2. PR은 하루 안에 끝낼 수 있는 크기로 만들어야 한다.
3. 커밋을 활용해 논리적 그룹을 만들어야 한다.

• 코드 스타일을 깔끔하게 유지하기
• 작성한 코드를 테스트하기

커밋 메시지 타입

<type>(<scope>): <subject>
type은 커밋의 종류를, scope는 커밋이 영향을 미치는 범위를 나타내고 subject에는 커밋의 간략한 설명을 적는다.

type 설명
feat : 기능 개발과 관련
docs : 주석/ReadMe 등 문서화 관련
test : 테스트 관련
fix : 버그나 typo 등을 수정 사항 관련
chore : 코드와 관련이 없는 내용들을 수정할 때 (License 등)
ci : CI/CD 등과 관련한 작업을 수행할 때

Linting 툴

자동으로 규칙을 체크해주는 툴
자바스크립트에서는 주로 ESLint와 Prettier를 사용한다.