Git 브랜치와 머지 — 협업의 기본

이 토픽을 마치면

브랜치가 왜 필요한지, 어떻게 만들고 합치는지, 그리고 충돌을 어떻게 해결하는지 이해하게 됩니다.

팀원 3명이 같은 코드를 동시에 수정합니다. A가 로그인을 만들고, B가 결제를 만들고, C가 버그를 고칩니다. 코드를 합칠 때마다 충돌이 나고, 누가 뭘 바꿨는지 추적하기 어렵습니다.

**브랜치(Branch)**는 코드의 독립적인 작업 공간입니다. 각자 브랜치에서 작업하고, 완성되면 합칩니다.

bash

# 브랜치 목록 확인
git branch

# 새 브랜치 만들기
git branch feature/login

# 브랜치 전환
git checkout feature/login

# 만들면서 전환 (한 번에)
git checkout -b feature/login

main(또는 master)은 기본 브랜치입니다. 새 기능을 만들 때는 브랜치를 따고, 완성되면 main에 합칩니다.

bash

# feature/login 브랜치에서 작업
git add login.js
git commit -m "feat: add login form"

git add auth.js
git commit -m "feat: add authentication logic"

이 커밋들은 feature/login 브랜치에만 존재합니다. main 브랜치에는 영향이 없습니다.

bash

# main으로 돌아가서
git checkout main

# feature/login을 main에 합침
git merge feature/login

feature/login의 커밋들이 main에 합쳐집니다. 충돌이 없으면 자동으로 완료됩니다.

같은 파일의 같은 부분을 두 브랜치에서 수정했으면 **충돌(Conflict)**이 발생합니다:

text

<<<<<<< HEAD
const greeting = "Hello";
=======
const greeting = "Hi";
>>>>>>> feature/login

<<<<<<<와 >>>>>>>사이의 내용을 확인하고, 원하는 코드만 남기면 됩니다:

javascript

const greeting = "Hi";

수정 후 커밋합니다:

bash

git add greeting.js
git commit -m "fix: resolve merge conflict"

실무에서는 git merge를 로컬에서 직접 하지 않습니다. Pull Request를 통해 합칩니다.

PR은 "이 코드를 main에 합쳐도 될까요?"라고 요청하는 것입니다. 코드 리뷰를 거치니까 버그가 줄어들고, 팀원이 코드 변경을 파악할 수 있습니다.

text

feature/login        — 새 기능
fix/cart-bug         — 버그 수정
refactor/auth        — 리팩토링
docs/readme-update   — 문서

종류/설명 형태가 일반적입니다. 팀마다 규칙이 다르니 프로젝트의 규칙을 따르세요.

브랜치는 코드의 독립적인 작업 공간이며, 완성되면 merge로 합칩니다. 같은 부분을 수정하면 충돌이 발생하고, 수동으로 해결해야 합니다. 실무에서는 Pull Request를 통해 코드 리뷰 후 merge합니다.