브랜치 & 병합 실습 예시

브랜치를 만들고 작업하고 병합하며 충돌을 푸는 흐름을 시나리오로 익히는 가이드 | ← 레퍼런스 문서로 돌아가기

대상 버전git 2.5x (2.50.1 기준)

이 파일의 목적매뉴얼의 명령을 실제 브랜치 작업 흐름에 묶어, 따라 하며 익히도록 보완합니다

레퍼런스 문서Branching_Manual.html — 각 시나리오에서 링크로 연결됩니다

작성일2026년 6월 16일

● 초급 Getting Started 새 브랜치를 만들어 작업하고, 끝나면 main에 합치고 정리하는 기본 흐름

G-1 초급 기능 브랜치를 만들어 작업하고 main에 병합하기

지금 my-site 폴더에서 main 브랜치에 있습니다. 새 '문의하기' 기능을 추가하려는데, main은 안정적으로 두고 따로 작업 공간을 만들고 싶습니다. 작업·커밋을 마친 뒤 다시 main으로 돌아와 합치고, 역할이 끝난 브랜치를 정리하는 것이 목표입니다. 그동안 main에는 다른 변경이 없습니다.

사용 요소

git branch git switch -c git switch git merge git branch -d

단계별 실행

새 기능 브랜치를 만들면서 바로 이동
git branch 목록에서 * 표시로 지금 main인지 확인한 뒤, git switch -c로 브랜치를 생성하고 그 자리로 옮긴다. 여기서 한 변경은 main에 영향을 주지 않는다.
```
git branch                       # 현재 브랜치 확인(* 표시)
git switch -c feature/contact    # 브랜치 생성 + 이동을 한 번에
```
새 브랜치에서 작업하고 커밋
파일을 추가·수정하고 커밋한다. 이 커밋은 main이 아니라 feature/contact 위에 쌓인다.
```
# ... contact.html 작성 ...
git add contact.html
git commit -m "문의하기 페이지 추가"
```
main으로 돌아와 병합하고 정리
합칠 대상인 main으로 먼저 이동한 뒤 병합한다. main이 갈라진 뒤 변하지 않았으므로 포인터만 앞으로 가는 Fast-forward가 일어난다. 병합된 브랜치는 -d로 안전하게 지운다.
```
git switch main                  # 합칠 대상으로 이동
git merge feature/contact        # main이 안 변했으면 Fast-forward
git branch -d feature/contact    # 병합 끝난 브랜치 정리
```

git switch -c feature/contact는 git branch feature/contact(생성만)와 git switch feature/contact(이동)를 한 번에 합친 것이다. 병합 단계에서 main이 갈라진 시점 이후로 새 커밋이 없으면 Git은 새 병합 커밋을 만들지 않고 main 포인터를 feature 끝으로 옮기기만 하는데, 이것이 Fast-forward다. 이력이 한 줄로 깔끔하게 이어진다.

입문 단계의 표준 흐름은 이렇다: main에서 git switch -c feature/x → 작업·커밋 → git switch main → git merge feature/x → git branch -d feature/x. 브랜치 이름은 feature/contact처럼 '용도/내용' 형태로 지으면 한눈에 무슨 작업인지 알 수 있다.

● 중급 Daily Workflow 양쪽이 같은 곳을 고쳐 생긴 병합 충돌을 마커를 직접 풀어 해결하는 단계

D-1 중급 병합하다 생긴 충돌을 직접 해결하기

feature/header에서 index.html의 제목 줄을 고쳤는데, 그동안 main에서도 같은 줄을 다르게 고쳤습니다. main으로 옮겨 git merge feature/header를 실행하니 충돌이 났습니다. 현재 main 브랜치에서 병합을 막 시도한 상태이며, 이 충돌을 손으로 풀어 마무리하는 것이 목표입니다.

사용 요소

git merge git status git add <파일> git merge --continue git merge --abort

단계별 실행

어떤 파일이 충돌했는지 확인
git status가 'both modified'로 충돌 파일을 알려 준다.
```
git status                       # both modified: index.html
```
파일을 열어 마커를 보고 직접 수정
파일에 아래처럼 마커가 들어가 있다. <<<<<<<~=======는 현재 브랜치(main, HEAD) 내용, =======~>>>>>>>는 feature/header 내용이다. 원하는 코드만 남기고 마커 세 줄을 모두 지운다.
```
<<<<<<< HEAD
  <h1>우리 회사 — 메인</h1>
=======
  <h1>우리 회사 홈페이지</h1>
>>>>>>> feature/header
```
해결한 파일을 add 해 '해결됨' 표시
마커를 모두 지운 파일을 스테이징해 Git에 "이 충돌은 풀었다"고 알린다.
```
git add index.html               # 해결됨으로 표시
```
병합을 마무리
병합을 완료하면 양쪽을 묶는 병합 커밋이 만들어진다. 메시지는 자동으로 채워진다.
```
git merge --continue             # 병합 커밋 작성 (git commit 으로도 가능)
```

양쪽 브랜치가 같은 부분을 다르게 바꾸면 Git은 어느 쪽이 맞는지 판단할 수 없어 멈추고 사람에게 넘긴다. 마커 사이에서 남길 코드를 고르고 마커 줄(<<<, ===, >>>)을 모두 지운 뒤 git add → git merge --continue 하면 해결된다. 충돌은 오류가 아니라 정상적인 협업 과정의 일부다.

마커를 지우지 않은 채 그대로 add·commit 하면 <<<<<<< 같은 기호가 코드에 섞여 버린다. 충돌이 너무 복잡해 손대기 어렵다면 git merge --abort로 병합 전 상태로 깨끗이 되돌리고 마음을 가다듬은 뒤 다시 시도하자.

● 고급 Power User AI에게 맡긴 위험한 작업을 실험 브랜치에서 굴리고, 병합하고, 실패하면 통째로 버리기

P-1 고급 AI 실험 브랜치를 안전하게 운영·병합·정리하기

AI 도구에게 큰 리팩터링을 맡기되 main은 절대 망가뜨리고 싶지 않습니다. 그래서 별도 실험 브랜치에서 작업하는데, 그사이 main에도 다른 수정이 들어갔습니다. 실험 브랜치에 main을 합쳐 충돌을 풀고, 결과가 좋으면 main에 병합 커밋으로 합치되, 만약 실험이 실패하면 브랜치를 통째로 버리려 합니다. 현재 main 브랜치에 있고, 로컬에서만 진행하는 단일 작업입니다.

사용 요소

git switch -c git merge git merge --continue git merge --no-ff git branch -D

단계별 실행

실험용 브랜치 생성·전환 (main 보호)
main에서 분기한 ai-refactor 브랜치를 만들어 옮긴다. 이제 여기서 AI가 무엇을 하든 main은 그대로다. 변경은 작게 나눠 커밋해 두면 중간에 잘못돼도 쉽게 돌아갈 수 있다.
```
git switch -c ai-refactor
# ... AI 리팩터링 ...
git add -A
git commit -m "결제 모듈 함수 분리"
```
main의 변경을 실험 브랜치로 가져와 충돌 해결
그사이 main에 들어온 수정을 실험 브랜치로 병합한다. 같은 파일을 양쪽이 고쳤다면 충돌이 나므로, 마커를 정리하고 add → merge --continue로 마무리한다.
```
git merge main                   # main의 변경을 실험 브랜치로
# (충돌 시 마커 정리)
git add app.py
git merge --continue
```
결과가 좋으면 main에 병합 커밋으로 합치기
실험이 성공했으면 main으로 돌아가 합친다. --no-ff를 쓰면 "여기서 AI 리팩터링을 합쳤다"는 병합 커밋이 항상 남아, 나중에 이력만 봐도 작업 단위가 또렷하다.
```
git switch main
git merge --no-ff ai-refactor    # 병합 커밋을 남기며 합침
git branch -d ai-refactor        # 병합 끝난 브랜치 정리
```
(실패 시) 실험 브랜치를 통째로 버리기
결과가 마음에 들지 않으면 합치지 않고 폐기한다. 지금 서 있는 브랜치는 지울 수 없으니 main으로 나온 뒤, 병합 안 된 실험이므로 -D로 강제 삭제한다.
```
git switch main
git branch -D ai-refactor        # 병합 안 된 실험을 강제 삭제
```

git merge main은 양쪽 브랜치의 같은 영역 변경이 충돌하면 멈추고 파일에 충돌 마커를 심는다. 사람이 마커를 풀어 git add로 "해결됨"을 표시하면 git merge --continue가 병합 커밋을 완성한다. 마지막 합치기에서 --no-ff는 Fast-forward가 가능한 경우에도 일부러 병합 커밋을 남겨, 나중에 어떤 기능이 언제 합쳐졌는지 이력에서 바로 보이게 한다.

AI에게 위험한 작업을 맡길 때는 항상 실험 브랜치부터 만드는 습관을 들이자. main은 처음부터 한 번도 건드리지 않으므로, 실험을 git branch -D로 통째로 버려도 main은 깨끗하게 그대로 남는다. 실패해도 잃을 게 없다는 점이 브랜치 실험의 핵심 이점이다.

-D(대문자)는 병합되지 않은 커밋까지 함께 버린다. 정말 폐기할 실험일 때만 쓰자. 또 이렇게 정돈한 브랜치를 원격에 올려 동료와 공유하거나, 이미 푸시된 커밋을 안전하게 되돌리는 방법은 별도 매뉴얼에서 다룬다.

git 2.5x(2.50.1) 기준 | 2026년 6월 16일 작성
← 브랜치 & 병합 매뉴얼 | GitHub 실습 →