728x90

협업을 위한 Git 사용 가이드

협업 시 Git을 올바르게 사용하지 않으면 충돌(merge conflict)이 자주 발생할 수 있습니다. 특히 main 브랜치에서 파생된 feature 브랜치에서 작업하고, PR(Pull Request)을 보낼 때 충돌이 생기는 경우는 협업 구조와 워크플로우에 대한 이해가 부족한 경우가 많습니다. 이 문서에서는 로컬, 원격(GitHub), 브랜치 전략을 중심으로 협업 시 Git을 효율적으로 사용하는 방법을 정리합니다.

1. Git 기본 구조 이해하기

▶︎ 로컬(Local) vs 원격(Remote)

로컬 저장소: 내 컴퓨터에서 작업하는 Git 저장소
원격 저장소(GitHub): 팀원들과 공유하는 중앙 저장소
push: 로컬 변경사항을 원격 저장소로 업로드
pull: 원격 저장소의 변경사항을 로컬로 가져오기
fetch + merge / rebase: 원격 내용만 가져오고 수동으로 병합 또는 재정렬

▶︎ 브랜치란?

브랜치는 독립적인 작업 단위입니다. 하나의 기능 또는 버그 수정마다 새로운 브랜치를 생성합니다.
main은 배포 가능한 안정적인 버전을 유지하는 브랜치입니다.
그 외 브랜치는 feature/기능명, fix/버그명 등으로 명명합니다.

# 브랜치 생성 및 이동
git checkout -b feature/login

2. 협업을 위한 브랜치 워크플로우

main 브랜치 최신화
git checkout main git pull origin main
기능 브랜치 생성
git checkout -b feature/your-feature
코드 작업 및 커밋
git add . git commit -m "feat: 로그인 기능 구현"
원격 브랜치 푸시
git push origin feature/your-feature
GitHub에서 Pull Request(PR) 생성
- PR 대상: feature/* -> main
- 리뷰어 지정 → 코드 리뷰 → 병합

3. merge conflict 방지 및 해결

▶︎ 충돌이 자주 발생하는 이유

main 브랜치가 변경되었는데, 내 브랜치가 오래된 상태에서 PR을 보낼 경우
같은 파일의 같은 부분을 동시에 수정한 경우

▶︎ 충돌 방지를 위한 습관

내 브랜치를 최신 main으로 수시로 rebase
git fetch origin git rebase origin/main
충돌 발생 시 수동으로 해결 후 rebase 이어서 진행
# 충돌 해결 후 git add . git rebase --continue
최종 push (강제)rebase는 커밋 히스토리를 변경하므로 force push 필요
git push --force-with-lease

4. GitHub PR 중 충돌 발생 시 대응법 (실제 상황 예시)

GitHub Pull Request 화면에서 다음 메시지를 본다면:

Merge blocked: 1 check failed
Merge conflicts must be resolved
The source branch is 24 commits behind the target branch

▶︎ 문제 원인

main 브랜치가 최신 상태인데, feature 브랜치가 오래된 상태여서 충돌 발생

▶︎ 해결 방법 (로컬에서 수동 rebase)

main 브랜치 최신화 후 rebase 시작
git checkout main git pull origin main git checkout feature/your-feature git rebase main
충돌 해결 (수동)
- Git이 충돌난 파일을 표시함
- 파일을 열고 <<<<<<<, =======, >>>>>>> 표시된 부분을 보고 어떤 코드를 남길지 결정
- 충돌 해결 후:
```
git add .
git rebase --continue
```
충돌이 여러 번 날 수 있음 → 계속 반복
마지막으로 강제 푸시
git push --force-with-lease
GitHub에서 PR 화면 새로고침 → Merge 가능해짐

5. rebase vs merge 차이점 정리

항목	merge	rebase
커밋 기록	브랜치 통합 시 병합 커밋 생성 (merge commit)	히스토리를 재작성하여 선형(linear) 커밋 흐름 유지
충돌 해결 방식	병합 시 1회에 해결	커밋 하나하나마다 충돌을 해결해야 할 수도 있음
기록 유지	원래 커밋 히스토리 보존	커밋 ID가 변경됨 (force push 필요)
GitHub 전략	단순 병합(Squash or Merge commit)	PR 전에 개인이 히스토리 정리 용도로 사용
사용 목적	빠른 병합, 리뷰 추적	깔끔한 히스토리 관리, 협업 전 정리

▶︎ 어떤 것을 사용해야 할까?

팀에서 히스토리 가독성을 중요시한다면 rebase
간편하고 안전한 병합을 원한다면 merge
일반적으로는 개인 브랜치에서 rebase로 정리 후 PR에서는 squash merge를 추천

6. 정리된 협업 전략 (Best Practice)

main 브랜치에는 직접 커밋하지 않기
기능 단위로 브랜치 생성: feature/, fix/, refactor/ 등
PR 전에 항상 main 기준으로 rebase
리뷰어를 지정하고 반드시 코드 리뷰 후 merge
merge 대신 rebase + squash 전략 사용 권장 (히스토리 깔끔함)

7. GitHub Pull Request 기본 절차

브랜치 푸시 후 PR 생성
리뷰어 등록 및 리뷰 요청
충돌 여부 확인 및 수정
Approve 이후 merge (또는 squash and merge)

마무리

Git은 단순히 버전 관리 도구가 아닌 협업의 핵심 도구입니다. 기능 개발 시 브랜치 전략과 병합 전략을 잘 이해하고 활용하면 충돌 없이 효율적인 협업이 가능합니다. 꾸준히 fetch, rebase, pull을 병행하며 동기화를 유지하는 습관이 중요합니다.

⚠️ 초보자라면 merge보다 rebase는 위험할 수 있으니, 팀 내에서 표준 워크플로우를 먼저 정하고 실습을 통해 익히는 것을 권장합니다.