빠른 흐름
git switch -c feature/login
# 작업 후
git switch main
git merge feature/login기본 흐름
어떤 브랜치 작업을 먼저 떠올리면 되나
| 상황 | 먼저 떠올릴 선택 |
|---|---|
| 새 기능 작업 시작 | git switch -c <branch> |
| 현재 브랜치 목록 확인 | git branch |
| 다른 브랜치로 이동 | git switch <branch> |
| 기능 브랜치를 기준 브랜치에 합치기 | git merge <branch> |
| 기능 경계를 히스토리에 남기기 | git merge --no-ff <branch> |
| 전환 전 미완성 변경 임시 보관 | git stash |
브랜치는 커밋 객체를 가리키는 이동 가능한 포인터일 뿐이다
Git에서 브랜치는 특정 commit 객체의 SHA를 담은 40바이트 참조 파일에 불과합니다. 새 브랜치를 만드는 비용이 거의 없는 이유가 여기에 있습니다. git switch -c feature/login은 현재 HEAD가 가리키는 commit SHA를 그대로 복사해 새 ref를 만들고, HEAD를 그 ref로 옮깁니다. 이 구조 덕분에 브랜치 전환은 파일을 복사하는 것이 아니라 포인터 하나를 바꾸는 작업이므로, 브랜치를 자주 만들고 버려도 저장소 크기가 늘지 않습니다.
git switch -c feature/login # 새 브랜치 생성 + 이동
git branch # 브랜치 목록 확인 (* = 현재 브랜치)
git branch -v # 각 브랜치의 최신 커밋 SHA 함께 확인미완성 변경이 있을 때 브랜치 전환하면 작업 트리가 오염된다
Git은 브랜치 전환 시 작업 트리를 목표 브랜치의 tree 객체 상태로 교체합니다. 이때 현재 브랜치에서 수정했지만 커밋하지 않은 파일이 있으면 Git은 충돌 가능성을 감지해 전환을 거부하거나, 변경을 그대로 목표 브랜치로 끌고 갑니다. 후자의 경우 다른 브랜치 작업 중에 이전 브랜치 변경이 섞이는 오염이 발생합니다. 전환 전 git status로 확인하고, 완료되지 않은 작업은 커밋하거나 git stash로 임시 저장해 두는 것이 안전합니다.
git status # 전환 전 반드시 확인
git stash # 커밋하기 애매한 중간 작업 임시 저장
git switch main
git stash pop # 돌아온 뒤 임시 작업 복원merge는 전략에 따라 fast-forward와 merge commit으로 나뉜다
git merge는 두 브랜치의 공통 조상(base commit)을 기준으로 변경을 통합합니다. main 브랜치가 feature 분기 이후 새 커밋이 없으면 Git은 fast-forward를 수행합니다. 이는 브랜치 포인터만 앞으로 이동하는 방식으로, merge commit이 생기지 않아 히스토리가 선형을 유지합니다. 반대로 양쪽 모두 새 커밋이 있으면 3-way merge가 이루어져 두 히스토리를 합치는 merge commit이 만들어집니다. 팀 컨벤션에 따라 --no-ff 옵션으로 항상 merge commit을 만들어 기능 브랜치 경계를 히스토리에 남길 수 있습니다.
git switch main
git merge feature/login # fast-forward 또는 3-way merge 자동 선택
git merge --no-ff feature/login # 항상 merge commit 생성 (기능 경계 명시)
git log --oneline --graph # 병합 결과 확인fast-forward와 merge commit은 히스토리에 남는 정보량이 다르다
기능 브랜치를 짧게 쓰고, main에 다른 커밋이 없는 상태라면 fast-forward가 가장 단순합니다. 반대로 "이 기능 브랜치가 언제 병합됐는지"를 나중에 추적해야 하는 팀이라면 --no-ff가 더 낫습니다. fast-forward는 기록이 깔끔하지만 브랜치 경계가 사라지고, merge commit은 히스토리가 조금 더 복잡해지지만 기능 단위가 명확하게 남습니다.
# fast-forward: main에 새 커밋이 없으면 포인터만 이동
git switch main
git merge feature/login
# 기능 브랜치 경계를 남기고 싶으면
git merge --no-ff feature/login충돌이 생겼을 때 merge는 중단 가능한 상태를 만든다
충돌 발생 시 Git은 충돌 마커(<<<<<<<, =======, >>>>>>>)를 파일에 삽입하고 merge를 중단 상태로 둡니다. 이 상태에서 직접 파일을 편집해 해결한 뒤 git add로 해결 완료를 표시하고 git merge --continue로 완료하면 됩니다. 충돌 해결이 복잡해 처음부터 다시 시작하고 싶다면 git merge --abort로 merge 이전 상태로 완전히 되돌릴 수 있습니다.
git merge feature/login # 충돌 발생
# 파일 편집으로 충돌 해결
git add <resolved-file>
git merge --continue # merge 완료
# 또는
git merge --abort # merge 취소, 이전 상태로 복귀체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 새 기능이나 실험 작업 시작 | git switch -c <branch> |
| 작업 트리 변경이 있는 상태에서 전환 | git stash 후 전환 |
| 기능 브랜치를 main에 합칠 때 | git merge <branch> |
| 선형 히스토리 유지하고 싶을 때 | git rebase 또는 fast-forward merge |
| 기능 경계를 명시적으로 남기고 싶을 때 | git merge --no-ff <branch> |
주의할 점
작업 중인 변경이 커밋되지 않은 상태에서 브랜치를 전환하면 변경이 목표 브랜치로 넘어가거나
전환이 거부됩니다. 전환 전에는 반드시 git status로 작업 트리 상태를 확인하고, 미완성 작업은
git stash로 임시 저장하거나 WIP 커밋으로 남겨 두어야 합니다. 이미 원격에 공유된 브랜치에
rebase 대신 merge를 선택하는 것이 협업자의 히스토리 충돌을 방지하는 기본 원칙입니다.
git switch main
# error: Your local changes to the following files would be overwritten by checkout:
# src/app.js
git stash
git switch main참고 링크
3 sources