Git 협업하기 개념 정리 1️⃣ (Git을 통한 협업)

이번 글은 코드잇 강의를 수강하면서 배운 내용을 주로 하여 정리되어 있습니다. (코드잇 스프린트 데이터 애널리스트 트랙 1기 훈련생)

---

Git을 통한 협업

---

Git을 통한 협업 개요

협업 과정은 프로젝트 규모가 작을 때는 문제가 없지만, 프로젝트의 규모가 커지다 보면 협업 과정 중에서 여러 문제들이 발생합니다.

협업에 관해 문제들이 발생하고 이를 해결하지 못한다면, 프로젝트 참여자들의 생산성이 눈에 띄게 낮아지고, 프로젝트의 성공 여부도 불투명해지게 됩니다.

협업 실패의 원인

1. Git과 GitHub에 대한 이해 부족: 이 도구들은 소스 코드 버전 관리와 협업을 효율적으로 관리하기 위해 필수적입니다. 그러나 이를 제대로 사용하지 못하면 코드 충돌, 버그 발생, 브랜치 관리 실패 등의 문제가 발생합니다.
2. 커뮤니케이션 스킬 부족: 효과적인 커뮤니케이션 능력이 부족하면 협업이 원활하지 않습니다. GitHub의 Pull Request, 코드 리뷰, 브랜치 관리 전략 등을 활용해 팀원 간 소통을 강화해야 합니다. 그렇지 않으면 역할과 책임에 대한 이해가 부족해지고 프로젝트의 효율성이 떨어집니다.

협업 실패가 초래하는 문제점들

• 업무 지연: 협업이 원활하지 않으면 업무 조율에 많은 시간과 노력이 필요하며, 이로 인해 전체 프로젝트 일정이 지연될 수 있습니다.
• 소통 부재: 협업 실패는 팀원 간의 소통 부족으로 이어지며, 소소한 오해가 커다란 문제로 번지고, 팀원 간의 신뢰가 깨져 프로젝트 실패로 이어질 수 있습니다.
• 중복 작업과 비효율: 중복 작업이 발생하거나 불필요한 일을 하게 되어 팀의 전반적인 생산성이 저하됩니다.

---

Git의 일반적인 사용 흐름

Git의 핵심 구조와 파일의 상태 변화

Git의 핵심 구조는 working directory, staging area, 그리고 repository로 구성되어 있습니다.

working directory에서는 실제 파일을 수정하며, 이 변경 사항을 다음 커밋에 반영하기 위해 Stage에 보관합니다.

git commit 명령어를 사용하면, staging area에 준비된 변경 사항이 repository로 이동하며, 새로운 버전이 생성됩니다.

 

파일 상태는 이 과정에서 'Untracked', 'Modified', 'Staged', 'Unmodified' 등으로 변화하게 됩니다.

• Untracked: Git이 아직 추적하지 않는 파일.
• Modified: 파일이 수정된 상태.
• Staged: 수정된 파일이 스테이징 에어리어에 추가된 상태.
• Unmodified: 커밋이 완료되어 변경사항이 없는 상태.
  
  
• 파일 상태의 예시 : 파일의 상태가 'Untracked'에서 'Unmodified'가 될 때까지 거치는 단계를 살펴본다면 이 과정은 staging area에 파일을 추가하고, 커밋의 과정을 거치는 과정입니다.
• 상태 변화의 순서 : Untracked → Modified → Staged → Unmodified

커밋 (commit)

커밋은 Git에서 매우 중요한 개념으로 작업 내용의 '스냅샷'을 의미하며, 한번 커밋하면 이력이 남습니다.

이런 특성 덕분에 문제가 발생했을 때 이전 상태로 쉽게 되돌릴 수 있습니다.

한마디로 말하자면 커밋은 Git에서 관리하는 가장 작은 단위의 버전이라고 할 수 있습니다.

 

커밋과 푸시의 차이

• 커밋 (commit): 로컬 저장소에 변경 내역을 저장하는 작업으로, 변경 사항의 스냅샷을 남깁니다.
• 푸시 (push): 로컬 저장소의 변경 내역을 원격 저장소에 업로드하여 다른 사용자와 공유합니다.

브랜치 (branch)

브랜치는 독립적으로 작업을 진행할 수 있는 개별적인 흐름을 의미하며, 여러 작업을 독립적으로 진행하고 나중에 병합할 수 있습니다.

브랜치는 특정 커밋을 가리키는 참조일 뿐이며, 이를 통해 여러 개의 '스냅샷'을 쉽게 전환할 수 있습니다.

이는 여러 개발자가 동시에 다양한 작업을 진행할 때 매우 유용합니다.

HEAD → 브랜치 → 커밋 (브랜치가 커밋을 가리킴)

로컬 저장소와 원격 저장소

• 로컬 저장소: 개인의 컴퓨터에 위치한 저장소로, 모든 작업이 이곳에서 이루어집니다.
• 원격 저장소: 인터넷상의 서버 등에 위치한 저장소로, 로컬 저장소의 변경 내역을 공유하거나 백업하는 데 사용됩니다.

로컬 저장소에서 원격 저장소로 보내는 git push 과정 중에서의 에러 설명

# 에러 메시지
fatal: The current branch master has no upstream branch.

To push the current branch and set the remote as upstream, use

git push --set-upstream origin main

• 이 에러는 현재 master 브랜치가 원격 저장소의 브랜치를 추적하고 있지 않기 때문에 발생합니다.
• 제안된 명령어: git push --set-upstream origin main는 로컬 main 브랜치를 원격 저장소의 origin/main브랜치로 푸시하면서 추적하도록 설정합니다.

Git의 매우 일반적이고 자주 사용하는 작업 흐름

1. git pull: 원격 저장소에서 최신 코드를 받아와 로컬 리포지토리를 최신 상태로 만듭니다.
2. git checkout -b add_profile_page: 새로운 기능을 위한 브랜치를 생성합니다.
3. 작업 수행: 파일을 수정하거나 추가합니다.
4. git add -A: 모든 변경 사항을 스테이징 에어리어에 추가합니다.
5. git commit -m "feat: add user profile page": 스테이징 에어리어의 변경 사항을 커밋하여 스냅샷을 생성합니다.
6. git push: 커밋한 변경 사항을 원격 저장소에 푸시하여 다른 팀원들이 볼 수 있게 합니다.

이러한 작업 흐름은 Git을 효과적으로 사용하여 협업하는 데 중요한 기본 절차입니다.

---

Github 훑어보기

GitHub는 개발자들에게 널리 알려진 원격 저장소 서비스입니다. GitHub는 단순한 원격 저장소를 넘어, 개발자들이 소통하고 협업하는 플랫폼으로 성장했습니다.

이러한 GitHub의 주요한 협업 기능들을 밑을 통해 설명하도록 하겠습니다.

팀을 만들기 위한 기능 : organization

GitHub의 Organization 기능은 팀 단위로 프로젝트와 저장소를 효율적으로 관리할 수 있게 합니다. 특히 회사나 대규모 조직에서 권한 관리와 보안을 향상하는 데 유용합니다.

• Organization: 다양한 프로젝트와 저장소를 통합 관리.
• Projects: 할 일 목록을 관리하고 프로젝트의 진행 상황을 시각화. (Projects 기능을 통해 작업 항목과 진행 상황을 파악하고 우선순위를 정할 수 있다.)
• Teams: 팀원들을 그룹화하여 협업을 용이하게 함.

Organization을 활용하면 Front-end, Back-end 등의 영역으로 나눠진 저장소를 한 곳에 모아 관리할 수 있습니다. 이는 팀원들 간의 협업을 더욱 원활하게 하고, 프로젝트의 통합 관리를 가능하게 합니다.

Projects 기능은 팀원들이 작업 항목과 진행 상황을 빠르게 파악하며, 효과적인 협업을 실현할 수 있도록 돕는 기능을 제공하고 있습니다.

그러나 Projects를 최대한 활용하기 위해서는 이슈 관리 등의 기본적인 협업 지식이 필요할 수 있습니다.

그리고 Organization의 핵심 기능으로, Teams를 얘기할 수 있는데, Teams 기능은 소속된 collaborator를 목적에 따라 그룹화하는 기능을 제공합니다.

Teams에서는 필요에 따라 다양한 팀을 만들고 운영할 수 있습니다.

이렇게 만들어진 팀들은 이후 Github의 Pull Request, Code Review, CODEOWNERS 등 다양한 기능에서 활용할 수 있습니다.

Issues

Issues는 버그 추적과 프로젝트 관련 토론을 위한 중요한 기능입니다.

• 버그 리포트: 프로젝트의 버그를 리포트하고 추적.
• 기능 요청: 새로운 기능에 대한 요청과 토론.
• 협업: 팀원들과의 의사소통과 협업 강화.

Issues는 프로젝트의 문제를 식별하고 해결하는 데 도움이 되며, 사용자와 개발자 간의 소통을 촉진합니다.

Pull Requests (PR)

Pull Request는 코드 변경 사항을 검토하고 병합을 요청하는 기능을 제공하고 있습니다.

• 코드 검토: 다른 사용자들에게 코드 변경 사항을 검토받음.
• 의견 교환: Pull Request를 통해 의견을 주고받고 피드백을 제공.
• 품질 향상: 코드 변경의 품질을 개선하고 버그를 예방.

Pull Request는 프로젝트에 기여할 수 있는 중요한 방법이며, 코드 리뷰를 통한 품질 향상을 이끌어냅니다.

Code Reviews

Code Reviews는 GitHub에서 코드 리뷰를 진행하는 기능입니다.

• 코드 검증: 다른 사용자의 코드를 검토하고 피드백 제공.
• 협업: 팀원들과 협업하여 코드 품질을 향상.
• 버그 예방: 코드 리뷰를 통해 버그를 예방하고 더 견고한 코드를 개발.

코드 리뷰는 팀 내 코드 품질을 높이고 더욱 효율적인 코드를 작성하는데 중요한 역할을 합니다.

 

GitHub는 개발자들이 소통하고 협업할 수 있는 중추적인 플랫폼으로 발전했습니다. GIthub에서 제공하는 다양한 기능을 활용할 수 있다면, 개발 커뮤니티에 적극적으로 참여하고 성장할 수 있습니다.

특히 Pull Request와 Code Review는 협업과 코드 품질 향상에 필수적인 도구입니다.

---

Pull Request(PR)

---

Pull Request란?

GitHub의 Pull Request(PR) 기능은 코드 변경 사항을 검토하고 병합하는 과정을 체계적으로 관리할 수 있게 도와줍니다.

PR을 통해 코드 리뷰를 요청하고 피드백을 받을 수 있어, 코드의 품질을 높이고 버그를 예방하는 데 큰 도움이 됩니다.

즉, Pull Request는 다른 깃허브 사용자들에게 자신이 작업한 내용을 검토하고 병합해달라고 요청하는 깃허브의 기능입니다.

변경 지점의 최소 단위인 commit 단위의 기록이, feature 단위의 기록이 PR로 남기 때문에 일종의 기록 혹은 자동화된 문서화라고 할 수 있으며, PR은 복구 가능한 시점을 만드는 것이라고도 할 수 있습니다.

 

이제 새로운 회사에 합류하여 PR을 만들고 어떤 방식으로 활용할 수 있는지를 살펴보겠습니다.

• 개인 프로젝트에서 Pull Request를 사용하는 경우
  • 체계적인 코드 검토: PR을 통해 자신이 작성한 코드를 체계적으로 검토하고 문서화할 수 있습니다.
  • 복구 가능한 시점: PR을 생성함으로써 복구 가능한 시점을 만들 수 있어, 실수한 경우 쉽게 되돌릴 수 있습니다.
  • 기록 관리: 변경 점의 최소 단위인 commit 단위의 기록을 feature 단위로 PR로 남겨 일종의 기록이나 자동화된 documentation 기능을 수행합니다.
• 팀 프로젝트에서 Pull Request를 사용하는 경우
  • 코드 리뷰: 팀원들이 PR을 통해 다른 사람이 작성한 코드를 확인하고 피드백을 제공하여 지식을 공유하고 코드의 품질을 개선할 수 있습니다.
  • 투명성: PR은 프로젝트의 투명성을 높여주고, 작성자의 의도를 쉽게 파악할 수 있게 도와줍니다.
  • 협업 강화: PR을 통해 코드의 작성 배경, 목적, 주요 내용을 문서화해 다른 팀원들의 작업이 쉬워집니다.

PR를 직접 만들기

• 작업할 프로젝트 생성하기
  GitHub에 로그인한 후, 우측 상단의 '+' 버튼을 클릭하고 'New repository'를 선택합니다. 'README.md' 파일을 체크한 후 저장소를 생성합니다.

• 프로젝트 클론하기

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

• 새로운 브랜치 생성하기

git checkout -b my-first-branch

• 코드 변경하기
  예시로 'README.md' 파일을 수정하거나 다른 파일을 수정합니다.
  
• 변경 사항 커밋하기

git add -A
git commit -m "this is my first branch commit"

• 변경 사항 푸시하기

git push origin my-first-branch

푸시한 후, 터미널에는 PR을 생성할 수 있는 URL이 출력됩니다. 이 주소를 클릭하여 GitHub 웹사이트로 이동합니다.

• PR 생성하기
  GitHub 웹사이트에서 'Create pull request'를 클릭합니다. 제목과 내용을 입력하고 'Create pull request' 버튼을 눌러 PR을 생성합니다.
  

PR(Pull Request)의 3가지 상태 : open, merge, closed

1. open : PR이 아직 검토가 완료되지 않았거나, 추가적인 작업이 필요한 상태 → 이 상태에서는 더 많은 커밋을 추가하거나, 토론을 진행하며 수정 요청 가능
2. merged : 해당 PR의 변경 사항이 승인되었고, 기존 브랜치에 통합되었다는 것을 의미 (merged는 3가지 분류로 나뉨
3. closed : 거부되었거나, 더이상 유효하지 않은 PR. 더이상 필요하지 않거나 다른 이유로 인해 종료된 상태.

---

PR merge

위에서 GitHub에서 Pull Request를 병합하는 내용에 대해 설명했었는데, 여기서 더 나아가 두 개의 브랜치를 머지하는 방법에 총 3가지의 방법이 있습니다.

이번 목차에서는 각 3가지 방법의 작동 방식과 장단점에 대해 설명하겠습니다.

1. merge commit을 만들며 합치기 : 이 방법은 두 브랜치의 변경 사항을 모두 유지하면서 병합합니다. 새로운 커밋이 추가되어 최종 병합이 완료되며, 각 브랜치의 변경 사항이 과거 커밋으로 보존됩니다.
   • 장점 :
     • 브랜치의 히스토리를 모두 유지하여 프로젝트의 진행 상황을 명확하게 추적할 수 있습니다.
     • 커밋 아이디가 바뀌지 않아 사용이 비교적 쉽습니다.
   • 단점 :
     • 커밋 히스토리가 복잡해질 수 있습니다. 다양한 브랜치에서 여러 작업이 이루어지면 커밋 로그가 빠르게 복잡해질 수 있습니다.
2. Squash and merge 하기 : 이 방법은 브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합합니다. 각 커밋에서 발생한 모든 변경 사항을 병합 후 하나의 새로운 커밋을 생성합니다.
   • 장점:
     • 커밋 히스토리를 간단하게 유지할 수 있습니다.
     • 각 커밋이 특정 Pull Request를 대변하여 의미를 이해하기 쉽게 됩니다.
     • PR에서 발생한 자잘한 문제들을 숨기고, 중요한 내용만 압축하여 담을 수 있습니다. 커밋 하나하나가 완성된 기능을 의미합니다.
   • 단점:
     • 작업의 상세한 이력을 잃게 됩니다.
     • 커밋 아이디들이 하나로 합쳐지며 사라지고 새로운 커밋 아이디가 생성되기 때문에 여러 명이 해당 브랜치를 기반으로 작업을 수행하고 있었다면 병합 시 복잡한 문제가 발생할 수 있습니다.
     • GitHub에는 해당 커밋 기록들이 남아 있으나, Git에서는 사라집니다.
3. Rebase and merge 하기 : 이 방법은 현재 브랜치를 타겟 브랜치에 재위치시키는 방식입니다. 타겟 브랜치의 커밋 위로 현재 브랜치의 모든 커밋을 옮겨 놓아 커밋 히스토리를 선형적으로 유지합니다.
   • 장점:
     • 깨끗하고 선형적인 커밋 히스토리를 만들어줍니다.
     • 히스토리 파악 및 코드 변화 이해가 쉬워집니다.
   • 단점:
     • 관련된 커밋의 ID들이 모두 바뀌게 되어 혼란을 초래할 수 있습니다.
     • 브랜치가 크게 분기된 경우 복잡한 충돌이 발생할 수 있습니다.
     • PR별로 나뉘어 있던 작업 이력이 하나의 선형적인 히스토리로 합쳐지기 때문에, 특정 기능의 구현 범위를 파악하기 어려울 수 있습니다.

병합 방법 선택하기

코드 상의 결과는 세 가지 방법 중 어떤 것을 사용하더라도 달라지지 않습니다. 각 방법의 장단점을 고려하여 프로젝트의 상황과 팀의 요구에 맞는 병합 방법을 선택하면 됩니다.

일반적인 병합 방법

• 초기 단계: Merge Commit 방식을 사용하여 브랜치 히스토리를 유지하고 변경 사항을 추적하는 것이 좋습니다.
• 프로젝트가 커지면: Squash and Merge나 Rebase and Merge 방식을 사용하여 커밋 히스토리를 간단하게 유지하거나 선형적인 히스토리를 만들 수 있습니다.

각 방법의 장단점을 팀원들과 함께 고려하여 적합한 병합 방법을 선택하고, 이를 통일하여 사용하면 협업 과정에서의 혼란을 줄일 수 있습니다.

---

Fork해서 PR 만들기

Fork는 GitHub나 GitLab 같은 호스팅 서비스에서 제공하는 기능으로, 기존 원격 Git 저장소(repository)를 사용자의 계정으로 복사하는 것을 의미합니다.

Fork된 저장소는 원본 저장소와 완전히 분리되어 있어, 사용자는 자신만의 저장소에서 자유롭게 변경 작업을 할 수 있습니다.

작업이 끝난 후에는 Pull Request(PR) 기능을 이용해 원본 저장소에 기여할 수 있습니다.

Fork와 브랜치의 차이점

• 브랜치 사용: 원본 저장소에서 직접 브랜치를 생성하고 작업한 후, PR을 통해 변경 사항을 제출합니다. 팀 내에서 협업하는 경우 이 방식이 효율적입니다.
• Fork 사용: 원본 저장소를 자신의 계정으로 복사한 후, 복사된 저장소에서 작업을 진행하고 PR을 통해 원본 저장소에 변경 사항을 제출합니다. 오픈소스 프로젝트나 대규모 프로젝트에서 주로 사용됩니다.

Fork로 PR을 생성하는 방법

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

오픈소스에 기여하는 방법

오픈소스 프로젝트에 기여하는 것은 개발자 커리어에 큰 도움이 되며, 개발 생태계를 더 이롭게 합니다. 다음은 기여하는 방법입니다:

1. 버그 보고: 프로젝트에서 발견한 버그를 Issues에 보고합니다.
2. 문서 개선: 프로젝트의 문서를 읽고 개선할 부분을 찾아 수정합니다.
3. 테스트 작성: 테스트 코드를 작성하여 프로젝트의 안정성을 높입니다.
4. Good First Issue 레이블 활용: GitHub의 Good First Issue 레이블을 통해 초보자들도 쉽게 참여할 수 있는 이슈들을 찾습니다. Good First Issue 사이트에서 원하는 언어로 필터링하여 기여할 이슈를 찾아보세요.

Fork로 Pull Request 생성하는 예시

• GitHub에서 원하는 프로젝트 페이지로 이동하여 'Fork' 버튼을 클릭합니다.
• Fork된 저장소로 이동합니다.
• 새로운 브랜치를 생성합니다

git checkout -b my-new-feature

• 변경 사항을 커밋하고 푸시합니다.

git add .
git commit -m "Add my new feature"
git push origin my-new-feature

• GitHub에서 Fork된 저장소로 이동하여 'New pull request' 버튼을 클릭합니다.
• 변경 사항을 반영할 원본 저장소와 브랜치를 선택합니다.
• PR을 작성하고 제출합니다.

---

PR 충돌 해결 방법

Git 충돌은 두 개의 브랜치가 병합될 때 동일한 파일의 동일한 부분에서 서로 다른 변경 사항이 있을 때 발생합니다. (충돌 : 병합하는 과정에서 발생하는 현상)

Git은 이 상황에서 어떻게 두 변경 사항을 병합해야 할지 알 수 없기 때문에 충돌이 발생했다고 판단합니다.

충돌이 발생하면 개발자가 수동으로 해결해야 합니다.

충돌 해결 과정

1. 충돌 발생시키기

밑의 예시는 충돌을 의도적으로 발생시키는 과정의 커맨드입니다.

# 새로운 변경 사항을 test/branch1에 만듭니다.
git checkout -b test/branch1
echo 'print("hello")' > test.py
git add test.py
git commit -m "feat: implement print hello"
git push origin test/branch1

# 새로운 변경사항을 main에 생성합니다.
git checkout main
echo 'print("codeit")' > test.py
git add test.py
git commit -m "feat: implement print codeit"
git push origin main

2. Pull Request 생성

test/branch1에서 원본 저장소로 PR을 생성하면 충돌이 발생합니다. GitHub에서 PR 페이지로 이동하여 충돌을 확인할 수 있습니다.

 

3. GitHub에서 충돌 해결하기

1. PR 페이지에서 Resolve conflicts 버튼을 클릭합니다.
2. 충돌이 발생한 파일의 충돌 부분이 표시됩니다.
3. 충돌을 해결하는 방법:
   • Accept Current: 현재 브랜치의 내용을 사용합니다.
   • Accept Incoming: 가져오는 브랜치의 내용을 사용합니다.
   • Accept Both: 두 가지 변경 사항을 모두 사용합니다.
   • Manual Edit: 충돌 부분을 직접 편집하여 해결합니다.
4. 충돌을 해결한 후 Mark as resolved 버튼을 클릭하고, Commit merge 버튼을 눌러 병합합니다.

4. 로컬에서 충돌 해결하기

 

   1. 충돌이 발생한 브랜치로 이동합니다.

git checkout test/branch1

   

   2. 메인 브랜치와 병합하여 충돌을 발생시킵니다.

git merge main

 

   3. 충돌이 발생한 파일을 편집기로 열고, 충돌 부분을 수정합니다. 충돌 부분은 <<<<<<<, =======, >>>>>>> 마커로 표시됩니다.   

   4. 수정된 파일을 저장한 후, 변경 사항을 커밋합니다.

git add test.py
git commit -m "resolve merge conflict"

   

    5. 변경 사항을 원격 저장소에 푸시합니다.

git push origin test/branch1

 

Git 충돌은 병합 과정에서 동일한 파일의 동일한 부분에서 서로 다른 변경 사항이 있을 때 발생합니다.

충돌은 수동으로 해결해야 하며, GitHub의 Resolve conflicts 버튼을 사용하거나 로컬에서 충돌을 해결할 수 있습니다.

추가적으로 VS Code와 같은 도구를 사용한다면 충돌을 시각적으로 쉽게 해결할 수 있습니다.

---

PR 충돌을 최소화하는 방법

Git 충돌은 머지 과정에서 시간과 비용을 소모하는 일이므로, 이를 최소화하는 전략을 사용하는 것이 중요합니다.

밑은 충돌을 최소화하고 효율적으로 해결하는 방법들입니다.

1. 최신 코드 유지

프로젝트를 진행할 때 항상 최신 코드를 유지하는 것이 중요합니다. 개발 중인 브랜치와 메인 브랜치 간의 차이가 커질수록 충돌 가능성도 증가합니다.

이를 해결하기 위한 방법은 주기적으로 메인 브랜치의 변경 사항을 작업 중인 브랜치로 병합하는 것입니다.

• 프로젝트 진행시 보통 하나의 main 브랜치를 기반으로 새로운 기능을 개발하기 위한 (feat) 브랜치 생성
• 개발 기간이 길어질수록 메인 브랜치와 개발중인 브랜치간의 차이가 커지며, 충돌 가능성도 증가하므로 동기화를 위한 정기적인 루틴을 만들어 두는 것이 중요
  • 정기적인 동기화 방법: 매일 아침 작업을 시작하기 전에 동기화 / 메인 브랜치에서 변경 사항을 주기적으로 병합

2. 작은 Pull Request 만들기

작은 규모의 PR은 충돌을 줄이고, 코드 리뷰를 더 쉽게 만들어줍니다. 작은 변화만 포함된 PR은 충돌이 발생하더라도 쉽게 해결할 수 있습니다.

작은 PR을 만들기 위한 팁:

• 기능 단위로 PR을 나누기
• PR을 자주 생성하여 작은 단위로 작업

3. 파일을 작게 만들기

큰 파일은 충돌 가능성이 높으므로, 파일을 작은 의미 단위로 나누어 구성하는 것이 좋습니다. 작은 파일은 관리하기도 쉽고, 충돌 발생 시 해결하기도 더 간단합니다.

• 파일을 작게 만드는 방법:
  • 기능별로 파일 분리
  • 관련된 코드끼리 모아 작은 파일로 유지

4. 동료들과 많은 커뮤니케이션 수행하기

효과적인 커뮤니케이션은 충돌을 줄이는 데 매우 중요합니다. 개발 과정에서 발생할 수 있는 충돌을 예방하기 위해 팀원들과 자주 소통하는 것이 좋습니다.

• 커뮤니케이션 전략:
  • 코드 변경 사항에 대해 사전 논의
  • 기능 구현 계획을 공유하여 작업 분배
  • 주기적인 스탠드업 미팅 또는 체크인

---

좋은 Pull Request란?(PR)

효과적인 PR은 협업에서 중요한 역할을 합니다. 이해하기 쉽고 명확한 PR은 리뷰어가 편하게 리뷰할 수 있으며, 코드의 품질을 높이는 데 기여합니다.

밑의 설명은 좋은 PR을 작성하기 위한 몇 가지 방법에 대한 설명입니다.

좋은 PR의 조건

1. 명확한 커뮤니케이션

PR의 목적, 변경 사항, 프로젝트에 미치는 영향을 명확히 설명합니다. 리뷰어가 PR을 이해하는데 필요한 정보를 제공하는 것이 중요합니다. (무엇을 변경하려고 하는지, 왜 그렇게 하려고 하는지, 그리고 그것이 어떤 영향을 미칠 것인지를 명확히 전달하는 것.)

• 제목과 설명: PR 제목과 설명은 변경 사항을 명확히 설명해야 합니다.
• 스크린샷과 링크: 필요에 따라 스크린샷이나 외부 문서의 링크를 포함합니다. 복잡한 문제를 해결할 때는 해결 방법을 상세히 설명하거나 관련 논의를 링크합니다.

2. 작은 Pull Request 만들기

작은 규모의 PR은 리뷰하는 시간을 줄이고, 리뷰어가 PR의 의도에 더 집중할 수 있게 합니다.

• 하나의 문제 해결: 하나의 PR은 하나의 문제를 해결하는 것이 좋습니다. 이는 코드의 목적을 명확히 하며, 리뷰어가 어떤 변경 사항에 주의를 기울여야 하는지 알기 쉽게 합니다.
• 작업 크기 제한: PR은 하루 안에 끝낼 수 있는 크기로 만드는 것이 이상적입니다. 대략 8시간 내에 완료할 수 있는 작업을 PR로 구성합니다.
• 커밋 활용: 커밋을 활용해 논리적 그룹을 만듭니다. 작은 PR들이 모여 한 덩어리의 기능을 하는 경우, 커밋으로 논리적 그룹을 만들어 전체 코드에서 어떤 역할을 하는지 파악할 수 있게 합니다.

3. 코드 스타일 유지

코드 스타일은 이해력과 가독성에 직접적인 영향을 미칩니다. 깔끔한 코드 스타일을 유지하기 위해 스타일 가이드를 준수합니다.

• 스타일 가이드 준수: 변수명, 함수명, 들여쓰기, 공백, 주석 작성 등에서 스타일 가이드를 준수합니다. 스타일 가이드는 각 프로그래밍 언어나 프레임워크마다 고유한 기준이 있으므로 이를 따릅니다.
• 일관성 유지: 코드 리뷰 과정에서 스타일 가이드가 지켜졌는지 확인하고 피드백을 주고받습니다. 스타일 가이드의 준수는 일관성 있는 코드 리뷰를 통해 이루어집니다.

4. 작성한 코드를 테스트하기

PR을 만들기 전에 코드가 제대로 작동하는지 테스트합니다. 이는 코드의 안정성을 보장하고, 리뷰 과정에서 발생할 수 있는 문제를 미리 해결하는 데 도움이 됩니다.

• 단위 테스트: 코드의 개별 부분이 의도한 대로 작동하는지 확인합니다.
• 통합 테스트: 여러 코드 조각이 서로 잘 작동하는지 검증합니다.
• 수동 테스트: 사용자 경험이 예상대로 흘러가는지 점검합니다.

테스트가 성공적으로 수행되면 그 결과를 PR에 명시적으로 표시합니다. 이는 리뷰어에게 신뢰감을 제공하며, 리뷰 과정을 간소화하는 데 도움이 됩니다.

---

PR를 위한 다양한 설정과 편의 기능

효율적인 협업을 위해 GitHub에서 제공하는 다양한 PR 관리 기능들을 활용하는 것은 매우 중요합니다. 이러한 기능들은 팀원들의 실수를 방지하고, 불필요한 커뮤니케이션을 줄이며, 협업의 효율성을 높이는 데 큰 도움이 됩니다.

GitHub Repository 설정

1. 일반 설정
   GitHub 프로젝트 페이지 상단바에서 Settings를 클릭하면 다양한 설정을 확인할 수 있습니다. 이 설정들은 PR 관리에 중요한 역할을 합니다.
2. Default Branch
   기본 브랜치는 일반적으로 main으로 설정되어 있습니다. 필요에 따라 develop 등으로 변경할 수 있습니다. 기본 브랜치를 변경하면 해당 브랜치로 머지를 요청하는 PR이 생성됩니다.
3. Pull Request의 머지 종류 제한하기
   PR의 머지 방식을 제한하여 팀 내 정책을 준수할 수 있습니다. Settings > General > Merge button에서 원하는 머지 방식을 설정합니다.
4. Pull Request가 머지된 이후, 자동으로 브랜치 삭제하기
   PR이 머지된 후 자동으로 해당 브랜치를 삭제하도록 설정할 수 있습니다. 이는 불필요한 브랜치를 관리하는 수고를 덜어줍니다.

브랜치 보호 설정

브랜치 보호 기능은 여러 개발자가 공유하는 브랜치에서 실수를 방지하는 데 중요합니다. Settings > Branches에서 설정할 수 있습니다.

1. Branch name pattern
   브랜치 보호는 브랜치 이름의 패턴을 기반으로 설정할 수 있습니다. 예를 들어, main 브랜치를 보호하고 싶다면 Branch name pattern에 main을 입력하면 됩니다. 패턴 매칭을 통해 feature/*와 같은 방식으로 여러 브랜치를 보호할 수 있습니다.
2. Branch Protection을 위한 다양한 설정들
   브랜치 보호 규칙에서 밑과 같은 다양한 설정들을 사용할 수 있습니다.
   • Require a pull request before merging: 머지하기 전에 반드시 PR을 생성하도록 설정할 수 있습니다. 이는 동료들의 리뷰를 받지 않고 푸시하는 실수를 막아줍니다.
   • Require approvals: 특정 수의 승인이 필요함을 명시할 수 있습니다. 예를 들어, 1명을 설정하면 1명이 승인하기 전까지 PR을 머지할 수 없습니다.
   • Require review from Code Owners: 특정 코드 영역에 대한 책임을 가진 사람이 리뷰해야만 머지가 가능하도록 설정합니다.
   • Require linear history: 이 설정을 활성화하면 선형적인 커밋 이력을 유지하도록 강제합니다.
   • Do not allow bypassing the above settings: 이 설정을 선택하면 위의 규칙들을 반드시 따라야 합니다.

---

Git과 GitHub를 통한 협업은 프로젝트의 성공에 중요한 역할을 합니다. 효과적인 브랜치 관리, PR 작성, 충돌 해결 등을 통해 코드 품질을 높이고 팀원 간의 협력을 강화할 수 있습니다. 이 글을 통해 Git과 GitHub의 활용법을 이해하고, 협업 과정에서 발생할 수 있는 문제를 미리 예방하며 효율적인 협업 환경을 구축할 수 있기를 바랍니다.

감사합니다.

 

---

출처 및 참고자료 : 코드잇 사이트 강의 'Git 협업하기' https://www.codeit.kr/topics/collaborating-with-git