[Git] 4. branch & merge

🚀 branch 를 사용하는 이유

---

• 프로젝트를 여러 버전으로 관리하기 위해
  • 실배포용, 테스트용, 기능추가 등
• 여러 작업들이 각각 독립되어 진행될 때
  • 로그인 기능, 게시판 기능, 코드 수정…
  • 각각의 branch 에서 작업한 뒤 확정된 것을 main branch에 merge

🚀 branch 생성하기

---

# 현재 로컬에 있는 브랜치 목록을 보여준다
git branch

# 원격 브랜치 목록을 보여준다
git branch -r

# feat/login 브랜치 생성
git branch feat/login

# feat/login 브랜치를 생성하고 해당 브랜치로 이동
git switch -c feat/login # 신규
git checkout -b feat/login # 기존 (checkout 명령어가 switch, restore로 분리)

# 브랜치 삭제
git branch -d (삭제할 브랜치명)

# 원격 브랜치 삭제
git push origin --delete (삭제할 브랜치명)

# 브랜치명 변경
git branch -m (기존 브랜치명) (새 브랜치명)

# 강제 삭제
git branch -D (삭제할 브랜치명)

🚀 branch 실무 활용

---

1️⃣ 기능/버그/작업 단위별 브랜치

• 가장 기본적인 활용 방식으로, 작업 단위를 분리해 독립적으로 개발
• 예
  • feature/user-profile: 새 프로필 기능
  • fix/login-error: 로그인 에러 수정
  • chore/update-dependencies: 라이브러리 업데이트
• 작업을 병렬로 진행, 코드 충돌 최소화

2️⃣ PR(Pull Request) 단위로 브랜치 활용

• 브랜치마다 작업이 완료되면 PR을 생성하여 코드리뷰 진행
• PR을 통해 코드 품질을 확인하고, 승인 후 main에 merge
• merge되면 작업 브랜치는 삭제 (히스토리 정리를 위함)

3️⃣ 브랜치를 환경별로 나눠서 작업

• 규모 있는 서비스에서는 배포 환경에 따라 브랜치를 구분해 안정성을 확보
• 예
  • main: 운영 환경(Production)용, 배포 기준 브랜치
  • develop: 개발 환경용, 기능 브랜치들을 머지해 통합 테스트
  • release/v1.2.0: 특정 버전 준비를 위한 배포 후보 브랜치
• 팀마다 Git flow, Github flow, trunk-based development 등 다양한 전략을 택한다.

4️⃣ 긴급 수정용 핫픽스 브랜치

• 운영 중 버그가 발생하면 main 브랜치에서 바로 hotfix/issue-name을 따서 수정 후 main에 merge (빠른 대응)
• 예

  git switch -c hotfix/payment-timeout main
  

5️⃣ 태그와 함께 릴리즈 관리

• 배포 준비가 끝난 브랜치(보통 main이나 release 브랜치)에서 태그를 찍어 해당 시점의 코드를 배포 및 추적
• 예

  git tag v1.2.0
  git push origin v1.2.0
  

회사별 Git 전략

• 작은 스타트업은 GitHub flow(기능 브랜치 → main에 PR 후 머지)로 단순하게 관리
• 대규모 서비스는 Git flow(메인/개발/릴리즈/핫픽스 브랜치 체계)를 써서 다양한 상황에 유연하게 대처

🚀 merge

---

• Git 에서 두 개 이상의 브랜치를 하나로 합치는(병합하는) 과정
• 개발자들은 독립적인 작업 공간(브랜치)에서 개발을 진행하고, 나중에 이 변경 사항들을 통합하여 관리

🚀 merge 의 필요성

---

• 동시 다발적 개발

  여러 개발자가 동시에 다른 기능이나 버그 수정을 작업

• 안정적인 코드 관리

  새로운 기능을 개발하는 동안 메인 코드베이스를 안정적으로 유지

• 작업 분리

  특정 기능이나 실험적인 변경 사항을 격리된 환경에서 개발하고, 완성되면 메인 브랜치에 통합

🚀 merge 의 작동 방식

---

1) Fast-forward merge

• 조건: 대상이 되는 브랜치(예: main)에 새로운 커밋이 없고, 합치려는 브랜치(예: feature)만 새로운 커밋을 가지고 있을 때 발생
• 작동 방식: 대상 브랜치의 HEAD를 합치려는 브랜치의 HEAD로 이동
• 장점: 히스토리가 깔끔하게 유지되고, 불필요한 커밋이 생기지 않는다.
• 단점: feature 브랜치가 언제 main 브랜치에 병합되었는지 기록이 남지 않아 추후 히스토리 파악이 어려울 수 있다. (이를 방지하기 위해 git merge --no-ff 옵션을 사용하여 강제로 병합 커밋을 생성할 수 있다)

2) Three-way merge

• 조건: 대상 브랜치(main)와 합치려는 브랜치(feature) 모두에서 새로운 커밋이 발생하여, 두 브랜치의 공통 조상 커밋(base commit) 이후로 각각의 변경 이력이 있을 때 발생
• 작동 방식: 아래 3가지 커밋을 비교하여 변경 사항을 합친다. 충돌이 없다면 Git이 자동으로 병합 커밋을 생성하고 병합을 완료한다.
  • main 브랜치의 최신 커밋
  • feature 브랜치의 최신 커밋
  • 두 브랜치의 가장 최근 공통 조상 커밋 (base commit)
• 장점: 병합 커밋이 생성되어 명확한 기록이 남기 때문에 히스토리 보존에 용이함
• 단점: 충돌이 발생할 수 있으며, 이 경우 수동으로 해결해야 함

🚀 merge 사용법

---

# 1. 병합하려는 대상 브랜치로 이동합니다. (예: main 브랜치에 feature 브랜치를 병합하려는 경우)
git switch main

# 2. 다른 브랜치(feature)를 현재 브랜치(main)에 병합합니다.
git merge feature

🚀 병합 충돌 (Merge Conflicts) 해결

---

1. 충돌 확인

   git merge 명령 실행 후 “CONFLICT” 메세지가 뜨고, git status 명령을 통해 충돌이 발생한 파일을 확인할 수 있다.

2. 파일 수정

   충돌이 발생한 파일을 텍스트 편집기로 열면 Git이 충돌 부분을 특수 마커(<<<<<<<, =======, >>>>>>>)로 표시해준다. 이 마커를 보고 원하는 내용을 선택하거나 조합하여 수동으로 수정한다.

    <<<<<<< HEAD
    현재 브랜치의 내용
    =======
    병합하려는 브랜치의 내용
    >>>>>>> feature
   

3. 수정된 파일 스테이징

   충돌을 해결한 후, 수정된 파일을 git add <파일 이름> 명령으로 스테이징 영역에 추가한다.

4. 병합 커밋 생성

   모든 충돌이 해결되고 파일이 스테이징 되면, git commit 명령으로 병합 커밋을 생성하여 병합을 완료한다. 이때 Git은 자동으로 병합 메시지를 생성한다.