Git 브랜치 충돌 및 PR 관리 핵심 가이드

다음은 브랜치 작업 중 발생한 문제와 해결 과정에서 알아둬야 할 핵심 포인트를 정리한 내용입니다.

✅ Git 브랜치 작업 시 알아둬야 할 핵심 정리

1. 브랜치 상태 확인은 항상 먼저

• git branch → 현재 브랜치 확인
• git status → 작업 트리 상태 확인
• git log --oneline --graph --decorate → 최근 커밋 흐름 확인

---

2. Push가 거부되는 원인

• 원격 브랜치(origin/development)가 로컬보다 앞서 있으면 → push 거부됨
• 이때는 pull 후 충돌 해결 후 push 필요
• 예시:

git pull origin development --rebase   # 추천
git push origin development

---

3. 브랜치가 잘못되어도 커밋은 보통 안전하게 남아 있음

• 커밋은 브랜치에 연결되어 있으니 쉽게 사라지지 않음
• 만약 작업이 사라진 것 같으면:

git reflog   # 최근 브랜치 이동 및 커밋 히스토리 추적

• 필요 시 이전 커밋 복구 가능

---

4. .gitignore와 캐시 제거

• .gitignore에 추가만으로는 기존 추적 파일이 제외되지 않음
• 이미 추적된 파일은 다음 명령어 필요:

git rm --cached <파일/폴더>

---

5. PR(풀 리퀘스트) 기본 흐름

1. feature 또는 development 브랜치에서 작업
2. 원격에 push
3. GitHub에서 base(받는 브랜치) 와 compare(보내는 브랜치) 확인
4. 리뷰 및 머지

base: 병합 대상 (보통 main)
compare: 병합할 작업 브랜치 (development)

---

6. main vs development 브랜치

• main → 배포용 / 안정적인 코드

• development → 기능 개발 및 통합 테스트용

• 일반적인 워크플로우:

  1. 기능 작업 → feature/xxx
  2. 머지 → development
  3. 최종 안정화 → main

---

✅ 기억할 핵심 명령어 모음

# 브랜치 확인 및 이동
git branch
git checkout <브랜치명>

# 원격 변경사항 가져오기
git pull origin development --rebase

# 캐시 제거 후 .gitignore 적용
git rm --cached <파일/폴더>

# 최근 커밋 및 브랜치 흐름 확인
git log --oneline --graph --decorate
git reflog

# 강제 푸시 (⚠️ 주의!)
git push origin development --force

---

💡 교훈

• 항상 현재 브랜치(main인지 development인지) 확인하고 작업
• push 거부 시 → pull → 충돌 해결 → push
• PR은 base와 compare 브랜치를 정확히 선택
• 중요한 작업은 git log와 git reflog로 확인 후 진행

---