[Git·GitOps 08] 브랜치 만들고 합치기: switch·merge와 fast-forward

기능을 고치는 동안 기준 상태를 유지하고 싶다면 브랜치를 나누면 됩니다. 폴더를 복사할 필요 없이 작업의 출발점에 이름을 붙이는 방식이에요. 작은 문서 수정으로 브랜치를 만들고 합치는 과정을 확인하겠습니다.

5편의 gitops-demo에서 main이 존재하고 작업 트리가 깨끗한 상태를 전제로 합니다. 미완료 변경이 있다면 먼저 커밋하거나 별도로 보관합니다. 브랜치 전환은 파일도 바꾸므로 진행 중인 편집을 무시하고 넘어가지 않습니다.

Git·GitOps 전체 연재 · 08 / 24

이 글의 목차

1. 기준을 확인하고 작업 브랜치를 만든다

git switch main
git status --short --branch
git switch -c feature/readme-usage
printf '\nUsage: run greeting.py with Python 3.\n' >> README.md
git diff -- README.md
git add README.md
git commit -m "Document how to run the greeting example"
git log --oneline --graph --decorate --all -8

switch -c는 브랜치를 만들면서 그곳으로 이동합니다. 이름은 팀이 식별하기 쉬운 feature/, fix/, docs/ 등을 사용할 수 있지만 Git이 그 접두사에 특별한 배포 의미를 부여하지는 않습니다. 자동화가 이름을 조건으로 사용한다면 팀 규칙이 됩니다.

2. main에서 변경을 받아들인다

git switch main
git merge --ff-only feature/readme-usage
git status --short --branch
git log --oneline --graph --decorate --all -8

그동안 main에 다른 커밋이 없었다면 fast-forward가 가능합니다. main의 포인터를 기능 브랜치가 있는 위치로 옮기는 방식이며 병합 커밋을 새로 만들지 않습니다. --ff-only는 이 이동이 불가능하면 중단하라는 뜻입니다.

실패했다고 변경이 망가진 것은 아닙니다. 두 브랜치가 갈라졌다는 신호일 수 있어요. 팀에서 정한 merge 또는 rebase 전략을 확인하고 합칩니다. 충돌 해결은 다음 편에서 별도로 연습합니다.

병합 기록을 남겨야 하는 경우

기능 단위의 합류점을 이력에 보존하려면 --no-ff로 병합 커밋을 만들 수 있습니다. 앞에서 이미 합친 브랜치에 같은 명령을 다시 실행하면 새 예제가 되지 않으므로 아래는 별도의 작은 브랜치를 사용합니다.

git switch -c docs/contributing
printf '\nContributions use short-lived branches.\n' >> README.md
git add README.md
git commit -m "Add contribution note"
git switch main
git merge --no-ff docs/contributing -m "Merge contribution documentation"
git log --oneline --graph --decorate -8

여기서는 두 부모를 가진 커밋이 생깁니다. 그래프는 합류 지점을 보여주지만 커밋 수가 늘어나는 비용도 있어요. 반대로 squash merge는 작업 브랜치의 여러 변경을 하나의 새 커밋으로 묶어 기준 브랜치에 기록합니다. 원래 커밋들의 조상 관계를 그대로 남기는 방식과 구분합니다.

방식	남는 형태	선택 이유
fast-forward	일직선 이력	분기 후 기준 변경이 없을 때 간단히 합류
merge commit	합류점과 부모 관계	기능별 병합 경로 보존
squash	묶은 변경 하나	리뷰 단위를 단일 커밋으로 정리
rebase	새 부모 위의 새 커밋	미공유 작업 이력을 기준에 맞춰 정리

작업 중 급히 브랜치를 바꿔야 한다면

아직 커밋할 단계는 아닌데 다른 수정을 먼저 처리해야 한다면 stash로 변경을 잠시 보관할 수 있습니다. -u는 미추적 파일까지 포함하지만 .gitignore로 제외한 파일은 담지 않습니다. 장기 보관이나 다른 PC와의 공유를 위한 백업으로 쓰지는 않습니다.

git stash push -u -m "Pause README work"
git stash list
# After returning to the original branch:
git stash apply 'stash@{0}'
git status

apply는 보관 항목을 남겨 둔 채 적용합니다. 내용을 확인하고 필요한 커밋을 남긴 뒤 git stash drop 'stash@{0}'으로 해당 항목을 지울 수 있습니다. 적용 중 충돌할 수 있으므로 보관했다는 이유만으로 다른 편집과 무조건 합쳐진다고 생각하지 않습니다. 동작은 git stash를 참고합니다.

합친 브랜치는 언제 지울까

git branch --merged main
git branch -d feature/readme-usage
git branch -d docs/contributing

-d는 병합 여부를 검사하며 삭제합니다. 브랜치 이름을 지워도 main이 참조하는 커밋이 함께 사라지는 것은 아닙니다. 서버의 원격 브랜치 삭제는 별개 명령이며, 다른 사람이 사용 중인지 확인하고 진행합니다.

squash나 rebase로 합친 브랜치는 원래 커밋이 main의 조상이 아니므로 -d가 거절할 수 있습니다. 이때 단순히 -D를 반복하기보다 리뷰와 병합 결과, 남길 커밋을 확인합니다. 실제 팀 작업은 서버의 보호 브랜치와 리뷰 규칙을 함께 사용하는 편이 좋습니다.

브랜치의 내부 구조는 Git Branches in a Nutshell, 병합 옵션은 git merge를 참고했습니다.

이전 글 · [Git·GitOps 07] 되돌리기 전에 고르는 명령: restore·reset·revert · 다음 글 · [Git·GitOps 09] 충돌 해결하기: 공통 조상과 3-way merge · 연재 목록과 예제 파일