[데브코스] Github으로 협업 시작하기(Branch, Pull Request)

🍎브랜치 만들기

효율적인 협업을 위해서는 일관된 브랜치 네이밍 규칙을 지키는 것이 좋다. 팀마다 정해진 방식이 있겠지만, 다음같은 네이밍 컨벤션을 사용하는 것이 보편적이다.

 

main 브랜치

👉 정상적으로 동작하는 버전이 저장되는 기본 브랜치

 

브랜치 분기

작업의 목적과 성격에 따라 브랜치를 분류하고 네이밍한다. 주로 다음과 같은 규칙을 사용한다.

• 기능 개발: feature/기능명 형태로 명명
• 출시 준비: release-x.x 형식으로 명명
• 긴급 수정: hotfix-x.x.x 형식으로 명명

브랜치 병렬 작업 이해하기

브랜치를 사용하는 주된 이유는 병렬 작업을 위해서이다. 브랜치는 독립된 작업 공간이므로, 서로 다른 작업을 동시에 진행할 수 있다.

 

브랜치 실험

1. feature/signup 브랜치에서 test.txt 파일을 추가
2. feature/login 브랜치로 전환
3. feature/login 브랜치에서도 test.txt 파일이 modified 상태로 표시

 

👉 변경 사항이 공유되는 이유는 아직 커밋을 하지 않았기 때문

 

 

브랜치 독립성과 커밋

브랜치를 생성했다고 바로 병렬 작업이 되는 것은 아니다. 커밋을 한 순간부터, 브랜치가 독립적으로 작동한다.

 

1. feature/signup 브랜치에서 커밋
2. feature/login 브랜치로 전환하여 test.txt 파일이 존재하는지 확인
3. feature/login 브랜치에는 test.txt 파일이 존재하지 커밋 히스토리에도 기록이 없다.

feature/signup 커밋 히스토리

feature/login

👉 브랜치 독립성은 커밋 기준으로 결정

 

주의사항

커밋할 때는 현재 작업 중인 브랜치를 반드시 확인하기!

 

Github 브랜치 생성(CLI)

협업을 위해서는 로컬에서 작업한 브랜치를 원격 저장소에도 공유를 해야 한다.

 

원격 브랜치 목록 확인

git branch -r

 

로컬 브랜치를 원격 저장소에 푸시

git push origin 브랜치명

 

로컬 브랜치를 푸시하면, 다른 사람들이 브랜치를 원격 저장소에서 확인하고 작업도 할 수 있다.

Github 브랜치 목록에 local 브랜치와 동일한 브랜치들이 생성됨

---

🍎Git Branch Merge 전략

Fast Forward

가장 단순한 병합 방식으로, 한 쪽 브랜치에만 변경사항이 있을 때 사용한다.

• 별도의 병합 커밋이 생성되지 않고 브랜치 포인터만 이동한다.
• 히스토리가 단순하고 직선적으로 유지되어 단순하다.
• 협업 시에는 잘 사용하지 않으며, 브랜치 히스토리를 명확히 남기기 어려운 방식이다.

3Ways

두 브랜치 모두에 변경 사항이 있을 때 사용하는 방식이다.

• 병합 시, Git이 A와 B의 변경 사항을 비교하여 정리한 후 병합 커밋을 생성한다.
• 독립적인 개발이 가능하며, 명확한 커밋 히스토리 유지가 가능하다.
• 충돌 발생 가능성이 있다.

---

🍎Pull Request와 Merge

코드를 변경하고 push하였다면 깃헙 레포지토리 페이지에서 Pull Request를 생성할 수 있다.

 

Pull Request란?

Github에서 코드 변경 사항을 다른 개발자에게 리뷰 요청하는 기능

 

Pull Request의 주요 기능

• 코드 리뷰: 팀원들이 변경 사항을 검토하고 피드백을 제공할 수 있다. 
• 자동화 테스트: CI/CD 파이프라인을 통해 자동으로 테스트를 진행할 수 있다.
• 토론: 변경 사항에 대한 논의가 가능하다.

Pull Request 작성법

• 코드 변경함~ 로그인 기능 구현함~ -> 절대 xxxxxx
• 풀리퀘스트를 작성할 때는 명확한 제목과, 변경 사항에 대한 상세한 설명을 작성하자

## 변경 사항
- 변경된 기능이나 버그 수정에 대한 설명

## 변경 이유
- 변경이 필요한 이유와 배경

## 테스트
- 테스트 방법과 결과

## 관련 이슈
- 관련된 이슈 번호나 링크

 

Merge가 머지

두 개의 브랜치를 하나로 합치는 작업

• Pull Request를 오픈하면, 자동 머지 가능 여부를 알려준다. 
• 머지를 할 때는 병합 커밋(Merge Commit)이 생성된다.
• 두 브랜치 간의 변경 사항이 충돌할 경우(Merge conflict), 수동으로 해결해야 한다.

충돌이 발생하여 자동으로 머지할 수 없는 경우

자동으로 머지 가능한 경우

 

Merge Conflict 해결 방법

Merge Conflict는 두 브랜치에서 동일한 파일의 같은 부분이 수정되었을 때 발생한다.

 

간단한 Merge Conflict는 웹 에디터에서 수정할 수 있다. <<<<<<<, =======, >>>>>>> 표시된 부분을 수정한다.

 

Merge 후 브랜치 관리

머지 후 사용하지 않는 브랜치는 삭제하는 것이 좋다. 복구 가능하니 브랜치 삭제를 습관화하자💡