[Git] Git Branch에 대한 이해와 활용

서쿠·2023년 5월 2일
1

Git-협업

목록 보기
4/8
post-thumbnail

Git Branch에 대한 이해와 활용

Git Branch는 Git에서 매우 중요한 개념 중 하나입니다.

이번 포스트에서는 Git Branch란 무엇인지, Git Branch를 활용하여 어떻게 코드를 관리할 수 있는지, 그리고 Git Branch를 활용한 협업 방법 등에 대해 살펴보겠습니다.

  • "모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다."
    ↳ 출처 : Git 브랜치 - 브랜치란 무엇인가

1. Git Branch란?

https://digitalvarys.com/git-branch-and-its-operations/

Git Branch는 Git에서 코드를 분기하여 관리하는 개념입니다.

  • Git에서는 기본적으로 main 혹은 master라는 하나의 브랜치를 가지고 있으며, 이 브랜치에서 새로운 브랜치를 만들어 작업을 진행합니다.

  • 새로운 브랜치를 만들면, 기존 브랜치와 독립적으로 코드를 변경할 수 있어 기능 개발, 버그 수정, 실험적 시도 등을 안전하게 수행할 수 있습니다.

2. Git Branch 관리 방법

2.1. 현재 브랜치 정보 확인

$ git branch
  • 현재 작업 중인 브랜치는 * 표시로 나타납니다.

예시:

  • 원격 브랜치까지 확인하고 싶다면:
$ git branch -a

예시:

$ git branch -a
* main
remotes/origin/HEAD -> origin/main
remotes/origin/main

해석:

  • * main → 지금 당신은 로컬의 main 브랜치에서 작업 중입니다.
  • origin/main원격 저장소(origin) 에 있는 main 브랜치입니다.
    • 즉, GitHub나 GitLab의 main 브랜치를 의미합니다.
  • remotes/origin/HEAD -> origin/main
    • origin이라는 원격 저장소의 기본 브랜치는 main임을 의미합니다.
    • HEAD는 그 기본 브랜치를 가리키는 포인터입니다.

Q. 지금 사용하는 브랜치 mainorigin/main이랑 같은 거야?

  • 👉 완전히 같지는 않아요.
    • main: 내 컴퓨터(Local) 에 있는 브랜치
    • origin/main: 원격 저장소(Remote) 에 있는 브랜치
      → 즉, 같은 이름이지만 서로 다른 공간에 있습니다.
      → 그리고, 우리는 이들을 서로 동기화(push/pull) 하면서 관리하는 것입니다.

보통은 이런 식으로 관리합니다 :

# 원격의 최신 내용을 내 로컬 main 브랜치에 반영
$ git pull origin main

# 로컬의 변경 내용을 원격 main에 반영
$ git push origin main

Q. 난 의심이 많아. 로컬 브랜치 main원격 브랜치 origin/main정말 연결되어 있는지(매칭되는지) 확인하고 싶어.

  • 👉 git status로 확인이 가능합니다.

입력:

$ git status

출력:

On branch main
Your branch is up to date with 'origin/main'.

2.2. Git Branch 생성

$ git branch <새 브랜치 이름>

예:

$ git branch feature/login

혹은 생성과 동시에 전환하려면:

$ git checkout -b feature/login

2.3. Git Branch 이름 변경

$ git branch -m <새 브랜치 이름>

현재 브랜치에서 변경하는 경우:

$ git branch -m feature/login feature/auth

2.4. Git Branch 삭제

$ git branch -d <삭제할 브랜치 이름>

강제 삭제 (병합 안 된 경우도 포함):

$ git branch -D <삭제할 브랜치 이름>

2.5. Git Branch 전환

$ git checkout <전환할 브랜치 이름>

또는 Git 2.23 이후에는 switch 명령도 사용 가능:

$ git switch feature/login

🔧 Git 실무 예시

✅ A. 새로운 기능 브랜치 생성 및 작업 (기획/기능 신규 착수 시)

# 1. 기준 브랜치(main 또는 dev) 최신화
$ git checkout main
$ git pull origin main

# 2. 새로운 기능 브랜치 생성 및 전환
$ git checkout -b feat/user-profile

# 3. 작업 후 커밋
$ git add .
$ git commit -m "✨ feat: 사용자 프로필 페이지 생성"

# 4. 원격 저장소에 새 브랜치 푸시
$ git push -u origin feat/user-profile

# 5. PR 생성 → 리뷰 → Merge → 브랜치 삭제

✅ B. 원격에 이미 존재하는 브랜치에서 작업 계속하기 (기존 브랜치 이어받기)

# 1. 저장소 clone (처음 받는 경우)
$ git clone https://github.com/your-org/your-repo.git
$ cd your-repo

# 2. 원격 브랜치 목록 확인
$ git branch -r

# 3. 작업할 브랜치 checkout (로컬 브랜치 생성 + 자동 트래킹)
$ git checkout feat/user-profile
# 또는 명시적으로
$ git checkout -b feat/user-profile origin/feat/user-profile

# 4. 작업 시작
$ git pull            # 혹시 최신 상태가 아닐 경우
$ git status
$ git add .
$ git commit -m "♻️ fix: 프로필 UI 수정"

# 5. 원격 저장소로 푸시
$ git push            # 이미 tracking 중이면 브랜치명 생략 가능

3. Git Branch 전략

Git Branch 전략은 협업 시 브랜치 명명 규칙, 생성/병합 흐름을 명확히 하기 위한 전략적 선택입니다. 아래는 대표적인 3가지 전략입니다.

3.1. Git Flow 전략

구성:

  • main: 실제 운영 중인 코드 (배포용)
  • develop: 개발 통합 브랜치
  • feature/기능: 기능 개발 브랜치
  • release/버전: 출시 준비 브랜치
  • hotfix/이슈: 운영 이슈 긴급 수정
# 예시: feature 브랜치 생성
$ git checkout -b feature/search-filter develop

3.2. GitHub Flow 전략

  • main에서 직접 브랜치를 파서 작업 후 Pull Request
  • CI/CD가 자동으로 동작하며 배포 가능
  • 빠른 반복과 간결한 구조에 적합

3.3. GitLab Flow 전략

  • GitLab Flow는 GitHub Flow와 Git Flow의 중간 형태
  • main, production, feature, bugfix, release 브랜치를 혼합적으로 운용
  • 환경(branch-to-environment) 기반 배포 연계가 자주 사용됨

4. Git Branch 협업 방법

4.1. 코드 리뷰를 위한 Git Branch 활용

$ git checkout -b feature/payment
$ git push origin feature/payment
  • GitHub에서 Pull Request 생성하여 코드 리뷰 요청
  • main 또는 develop 브랜치로 병합하기 전 리뷰 필수

4.2. 팀 협업에서 브랜치 규칙 예시

브랜치 타입명명 규칙용도
기능 추가feature/<기능명>새 기능 개발
버그 수정bugfix/<이슈명>발견된 버그 수정
긴급 패치hotfix/<이슈명>운영 중 긴급 수정
배포 준비release/<버전>QA 및 배포 전 최종 검수용 브랜치
실험/개인 테스트experiment/<주제>실험적 코드 테스트

5. 발생 가능 문제 및 해결방법

5.1. 충돌 발생 예시 및 해결

Auto-merging app.py
CONFLICT (content): Merge conflict in app.py

해결 방법:

  1. app.py 파일을 열어 <<<<<<<, =======, >>>>>>> 로 표시된 부분을 확인
  2. 원하는 코드만 남기고 나머지 삭제
  3. 수정 후 add & commit:
$ git add app.py
$ git commit -m "Resolve merge conflict in app.py"

6. Git 충돌 해결 실습과 rebase vs merge 비교

6.1. 충돌(Conflict)이란?

Git에서 충돌(conflict) 은 두 브랜치에서 동일한 파일의 같은 라인을 수정하고 병합할 때 발생합니다. Git은 어떤 변경을 적용해야 할지 자동으로 결정할 수 없기 때문에, 사용자가 수동으로 해결해야 합니다.


6.2. 실습 예제: 충돌 상황 만들기

# main 브랜치에서 새로운 파일 생성
$ git checkout -b main
$ echo "console.log('Hello from main');" > app.js
$ git add app.js
$ git commit -m "Main: Add greeting message"

# feature 브랜치 생성 및 수정
$ git checkout -b feature
$ echo "console.log('Hello from feature');" > app.js
$ git commit -am "Feature: Update greeting message"

# main 브랜치에서 다른 내용으로 수정
$ git checkout main
$ echo "console.log('Hello from MAIN branch');" > app.js
$ git commit -am "Main: Change greeting message"

이제 feature 브랜치를 main에 병합하려고 하면 충돌이 발생합니다.


6.3. 충돌 해결 및 병합

# feature 브랜치에서 main 병합 시도
$ git checkout feature
$ git merge main

출력:

Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts and then commit the result.

app.js 파일을 열어보면 아래와 같은 충돌 마커가 표시됩니다.

<<<<<<< HEAD
console.log('Hello from feature');
=======
console.log('Hello from MAIN branch');
>>>>>>> main

해결 방법:

  1. 원하는 코드만 남기고 수정:
console.log('Hello from BOTH branches');
  1. 수정 후 저장, add & commit
$ git add app.js
$ git commit -m "Resolve conflict in app.js"

이제 충돌이 해결되었습니다.


6.4. Merge vs Rebase

항목mergerebase
목적두 브랜치를 통합브랜치 기반을 최신 커밋으로 변경
커밋 이력브랜치 병합 히스토리 유지 (merge commit)커밋 히스토리를 깔끔하게 재작성
사용 상황협업 기록을 명확히 남기고 싶을 때개인 브랜치 정리, 깔끔한 히스토리 관리 시
충돌 발생 시점병합 시점rebase 과정 중 각 커밋마다 충돌 가능성 있음
명령어 예시$ git merge main$ git rebase main

6.5. Rebase 실습

# feature 브랜치에서 main 변경 사항을 rebase
$ git checkout feature
$ git rebase main

중간에 충돌이 발생하면 동일하게 수동 해결 후:

$ git add app.js
$ git rebase --continue

전체 rebase 중단은:

$ git rebase --abort

✅ 정리

  • merge병합 이력을 명확히 보여주는 반면,
  • rebase히스토리를 깔끔하게 정리하는 데 유리합니다.
  • 협업 시에는 보통 merge를, 개인 브랜치 정리에는 rebase를 활용하는 것이 권장됩니다.
  • 충돌은 Git 협업에서 빈번하게 발생하며, 수동으로 충돌 마커를 읽고 해결하는 역량이 중요합니다.
profile
Always be passionate ✨

0개의 댓글