Git/GitHub - Shared Repository Model & Pull Request(PR) Workflow

 

Shared Repository Model

 

여러 협업자가 동일한 저장소(Repository)를 공유하며 작업하는 방식

 

• Push 권한을 부여받은 협업자가 직접 브랜치를 만들고 수정한 후 병합 가능
• 조직(Organization) 또는 개인 저장소에서 공동 작업을 수행

 

 

Add collaborators

 

 

1. GitHub 레포지토리에서 Settings → Collaborators로 이동

Settings

Collaborators

 

 

2. Add people 버튼 클릭

Add people

 

 

3. 협업자의 GitHub 사용자명 또는 이메일 입력 후 초대

Find people

 

 

협업자가 초대를 수락하면 레포지토리에 접근 가능

 

 

 

레포지토리 공개 여부 설정

 

Public :  누구나 접근 가능

Private : 초대를 받은 사용자만 접근 가능

 

 

 

협업 브랜지 전략 및 브랜치 생성

 

브랜치 전략 정하기

 

기본적으로 main 브랜치를 사용하지만, 협업 중 충돌을 방지하려면 새로운 브랜치에서 작업한 후 Pull Request를 활용하는 것이 좋음

 

 

새로운 브랜치 생성 및 작업

git switch -c 브랜치이름 # 새 브랜치 생성 후 이동
git add .
git commit -m "커밋메세지"
git push origin 브랜치이름 # 원격 브랜치로 푸시

협업자에게도 브랜치 전략(예: PR을 통해 병합)을 공유

 

 

Pull Request (PR) 워크플로우 사용

 

1. 협업자가 새로운 브랜치에서 작업 후 푸시

2. GitHub에서 Pull Request 생성 or GitHub CLI(gh) 사용해서 PR 생성

3. 코드 리뷰 후 병합

 

→ 기본적으로 git push 후 GitHub에서 직접 PR 생성해야 함

→ GitHub CLI를 쓰면 터미널에서 바로 PR 만들 수 있음

 

 

ReadMe 파일 작성

 

레포지토리의 사용법, 기여 방법 등을 협업자들에게 알려주려면 README.md 파일을 작성

• 프로젝트 설명
• 설치 및 실행 방법
• 기여 가이드라인 (예 : 브랜치 네이밍 규칙, 코드 스타일)

 

 

*gh옵션

--draft	초안 PR로 생성 (완성되기 전에 올려놓고 리뷰 받을 때 유용)
--assignee subin	PR 담당자 지정
--reviewer jh,ty	PR 리뷰어 지정
--label feature,backend	PR에 라벨 추가
--web	PR을 만들고 GitHub 웹사이트에서 바로 열기

 

 

 

Pull Request(PR)

 

새로운 기능 개발, 버그 수정 등의 변경 사항을 기존 코드베이스(main 등)로 병합 시, 코드 리뷰, 검토, 승인 과정을 거치기 위한 과정

• 코드 리뷰(Code Review)
  PR을 통해 리뷰어를 지정하고 코드 품질을 높임
  CI/CD(자동 테스트)와 연계하여 머지 전에 코드 검증 가능
• 히스토리 관리(History & Documentation)
  이슈 트래킹 & 변경 사항 기록을 위한 문서 역할
  "어떤 변경 사항이 왜 반영되었는지"
  팀 내에서 "누가 어떤 작업을 했는지" 투명하게 관리
• 충돌 방지 및 조정(Conflict Resolution)
  여러 사람이 같은 main을 직접 수정하면 충돌 가능성이 높음
  PR 사용 시 머지 전 충돌을 미리 해결 가능
• 승인 프로세스(Approval Process)
  PR 승인(Approval)을 요구하면 팀원 간 합의된 코드만 반영 가능
  Protected Branch 설정이 있다면 PR 없이 main이 직접 push 불가

→ PR에 댓글(Comment)의 형태로 피드백을 남기는 것은 누구나 가능하지만, PR을 공식적으로 승인(Approve)하거나 변경(Request changes)을 요청할 수 있는 사람은 저장소에 최소 "읽기(Read)" 권한 이상을 가진 사람들만 가능

→ 개인 레포지토리의 경우, 협력자를 추가할 때 기본적으로 쓰기(Write)권한이 부여됨

 

 

개인 계정 레포지토리의 권한 

 

소유자(Owner)

레포지토리의 완전한 제어 권한을 가짐

협력자 초대, 레포지토리 설정 변경, 삭제 등의 작업 수행 가능

 

협력자(Collaborator)

소유자가 초대한 사용자로, 기본적으로 코드에 대한 읽기 및 쓰기 권한을 가짐

• 읽기(Read) : 코드를 보고, 이슈를 생성하고, RP(Pull Request)을 제출할 수 있음
• 쓰기(Write) : 코드를 보고, 변경하며, 푸시할 수 있음

 

GitHub PR 생성 방법

 

Compare & pull request

• 변경된 내용을 main과 비교 후 PR 생성

New pull request

• main 브랜치에 병합하고 싶은 브랜치를 선택
• PR 제목과 설명 작성

 

PR 상태

 

• Able to merge. These branches can be automatically merged.
  충돌 없이 자동으로 병합 가능
• Can’t automatically merge. Don’t worry, you can still create the pull request.
  충돌 발생 → 수동으로 충돌 해결 후 병합 필요

 

 

Git 브랜치 관리 및 Merge 시나리오

 

브랜치를 만들어서 작업 후 main에 머지하는 과정

git switch -c feature-branch  # 새 브랜치 생성 후 이동
# 코드 수정 후 commit
git add .
git commit -m "Add new feature"
git push origin feature-branch  # 원격 브랜치로 푸시

1. GitHub에서 PR 생성

2. 코드 리뷰 후 Merge Pull Request

3. 병합된 브랜치는 삭제 가능 (git push origin --delete 브랜치이름)

 

 

Merge Conflict 해결 방법

 

같은 main에서 분기된 다른 브랜치가 먼저 main으로 병합되었을 경우 발생

내가 작업한 브랜치에서 main의 최신 상태를 반영해야 함

 

Conflict 해결 프로세스

git switch main
git pull origin main  # 최신 main 가져오기
git switch my-branch  # 내가 작업한 브랜치로 이동
git merge main  # 최신 main과 병합

충돌 발생 시, Git이 충돌 파일을 알려줌

 

충돌된 파일을 수동으로 수정 후:

git add .
git commit -m "Resolve merge conflict"
git push origin my-branch  # 충돌 해결 후 푸시

GitHub에서 PR을 다시 확인하고 Merge 진행

 

 

PR 관련 기능

 

• Reviewers : 코드 리뷰를 요청할 대상
• Assignees : 해당 PR 담당자
• Labels : PR의 성격을 나타내는 태그 (ex. bug, features, enhancement)
• Projects : 프로젝트 보드에서 PR을 트래킹할 수 있도록 추가
• Milestone : 특정 기간 내에 해결할 이슈들을 묶어 관리

 

PR 진행 과정

 

1. Start Review: 코드 리뷰 시작

2. Merge Pull Request: 코드 리뷰가 끝나면 main에 병합

3. Close Pull Request: PR을 병합하지 않고 닫을 경우

4. Confirm Merge: 병합을 최종 확정

 

 

GitHub CLI(gh)를 사용한 PR 자동화

 

보통 PR은 GitHub 웹사이트에서 생성 하지만, GitHub CLI(gh)를 사용하면 터미널에서 바로 PR을 만들 수 있음

 

 

GitHub CLI 설치

brew install gh #macOS
gh auth login #GitHub 로그인

 

 

터미널에서 PR 생성

git push origin 브랜치명
gh pr create --base main --head 브랜치명 --title "제목" --body "내용"

• --base main
  main 브랜치로 병합할 것임을 지정
• --head 브랜치명
  현재 브랜치에서 PR 생성
• --title "제목"
  "제목" 부분에 PR 제목 지정
• --body "내용"
  "내용" 부분에 PR 설명 입력

 

GitHub 웹사이트에서 확인법

gh pr view --web

 

 

*추가 옵션

--draft # 초안 PR로 생성 (완성되기 전에 리뷰 요청 가능)
--assignee 이름 # PR 담당자 지정
--reviewer 어쩌구,저쩌구,,.. # 리뷰어 지정
--label # PR에 라벨 추가
--web # PR을 만들고 GitHub 웹사이트에서 자동으로 열기

 

 

* Assignee vs. Author

 

PR 요청자 (Author)

PR을 생성한 사람은 자동으로 Author로 기록됨

--assignee를 지정하지 않아도 PR 요청자는 자동으로 표시됨

 

담당자(Assignee)

PR을 처리해야 할 담당자를 지정할 때 사용

팀 프로젝트에서 특정 개발자가 검토 & 병합해야 할 경우 --assignee를 사용

 

 

Assignee를 사용하는 이유

• 팀 프로젝트에서 PR 담당자를 명확히 지정
  --assignee
• 디자이너/QA 팀이 검토
• GitHub의 "Assigned to me" 필터 활용
  예 : 내가 담당한 PR만 보기
• 자동화된 GitHub Actions과 연동 가능
  예 : Assignee에게 Slack 알림 보내기

Assignee가 필요 없는 경우

• 혼자 작업하는 프로젝트
• 모든 PR을 같은 사람이 리뷰하고 병합하는 경우