Git switch 사용법

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

Git switch 사용법

git switch는 브랜치를 전환하거나 새 브랜치를 만들고 곧바로 이동할 때 쓰는 명령이다. 2026년 7월 3일 기준 Git 공식 문서는 이 명령을 브랜치 전환 전용 도구로 설명하며, 파일 복원까지 함께 맡는 git checkout보다 의도를 더 분명하게 드러낸다.

실무에서 핵심은 네 가지다. 기존 브랜치로 이동하는지, 새 브랜치를 만드는지, 작업 중인 변경을 유지한 채 옮길지, 임시로 detached HEAD 상태에 들어갈지를 먼저 나눠야 한다. 이 글은 Git 2.55.0 공식 문서를 기준으로 git switch의 기본 동작과 자주 쓰는 옵션을 정리한다.

git switch는 언제 쓰는 명령일까?

Git 공식 문서의 설명은 단순하다. 지정한 브랜치로 전환하고, 작업 트리와 index를 그 브랜치 상태에 맞춘다. 즉 파일 일부만 꺼내 오는 명령이 아니라 현재 작업할 브랜치를 바꾸는 명령이다.

최근 Git 사용법에서 브랜치 이동은 switch, 파일 복원은 restore로 역할을 나누는 이유도 여기에 있다. 팀 문서나 교육 자료를 새로 쓴다면 checkout 하나로 여러 동작을 설명하기보다 역할을 분리하는 편이 실수를 줄이기 쉽다.

가장 자주 쓰는 명령은 무엇일까?

상황	권장 명령	의미
기존 브랜치로 이동	git switch main	현재 작업 브랜치를 main으로 바꾼다.
새 브랜치를 만들고 바로 이동	git switch -c feature/login	브랜치를 생성한 뒤 전환한다.
이전 브랜치로 되돌아가기	git switch -	직전에 있던 브랜치나 커밋으로 빠르게 돌아간다.
원격 브랜치를 따라 새 로컬 브랜치 생성	git switch feature/api	조건이 맞으면 추적 브랜치를 자동 생성한다.
커밋을 잠시 확인	git switch --detach HEAD~2	브랜치에 붙지 않은 detached HEAD로 이동한다.

문서 기준으로 git switch는 git checkout보다 사용 범위가 좁다. 대신 "브랜치를 바꾸는 중인지"가 명확해서 초보자와 팀 문서 모두에서 설명이 쉬워진다.

새 브랜치를 만들 때는 -c와 -C를 어떻게 나눌까?

-c 또는 --create는 새 브랜치를 만들고 곧바로 전환한다. 문서상 이 동작은 git branch <name> 후 git switch <name>와 비슷하지만, 전환이 실패하면 중간 상태로 브랜치가 남지 않도록 한 번에 처리된다.

-C 또는 --force-create는 같은 이름의 브랜치가 이미 있으면 그 브랜치를 지정한 시작점으로 재설정한 뒤 전환한다. 따라서 기존 브랜치 포인터를 바꾸는 효과가 있으므로, 협업 중인 공유 브랜치에는 보수적으로 써야 한다.

작업 중인 변경이 있어도 브랜치를 바꿀 수 있을까?

기본적으로는 현재 변경이 대상 브랜치 전환 과정에서 손실될 수 있으면 명령이 중단된다. Git 공식 문서는 손실 위험이 없으면 깨끗한 작업 트리가 아니어도 전환이 가능하다고 설명한다.

문제가 되는 파일이 겹칠 때 선택지는 두 가지다. 변경을 버리고 대상 브랜치 상태로 맞추려면 --discard-changes를, 변경을 가능한 한 이어 가려면 --merge를 검토한다. 둘 다 결과가 강하므로 실행 전 git status로 범위를 확인하는 편이 안전하다.

--merge와 --discard-changes 중 무엇이 더 맞을까?

옵션	적합한 상황	주의점
--merge	현재 수정분을 새 브랜치 문맥으로 최대한 이어 가고 싶을 때	재적용 과정에서 충돌이 나면 stash 항목이 남을 수 있다.
--discard-changes	현재 수정분을 버리고 대상 브랜치 상태로 즉시 맞추고 싶을 때	작업 트리와 index 변경이 버려질 수 있다.

Git 2.55.0 문서 기준으로 --merge는 겹치는 변경이 있을 때 자동으로 stash한 뒤 전환 후 다시 적용하는 방식이다. 반면 --discard-changes는 현재 작업 트리와 index를 전환 대상에 맞춰 되돌리는 쪽에 가깝다.

 

 

원격 브랜치도 자동으로 잡아 줄까?

그럴 수 있다. 공식 문서에 따르면 로컬에 해당 이름의 브랜치가 없더라도, 정확히 하나의 remote에 같은 이름의 추적 브랜치가 있으면 --guess 기본 동작에 따라 로컬 브랜치를 만들고 추적 설정까지 한 번에 처리한다.

여러 remote에 같은 이름의 브랜치가 있으면 모호해질 수 있다. 이때는 checkout.defaultRemote 설정으로 선호 remote를 정하거나, 아예 git switch -c local-name --track origin/feature/api처럼 명시적으로 쓰는 편이 더 안전하다.

git switch -는 왜 자주 쓰일까?

-는 문서상 @{-1}의 축약형이다. 직전에 전환했던 브랜치나 커밋으로 빠르게 돌아갈 수 있으므로, 두 브랜치를 오가며 비교하거나 긴급 수정 후 원래 작업으로 복귀할 때 특히 편하다.

예를 들어 기능 브랜치에서 작업하다가 main으로 잠깐 이동해 로그를 확인한 뒤 다시 돌아와야 한다면 git switch main 후 git switch - 조합이 가장 단순하다.

detached HEAD는 언제 써야 할까?

git switch --detach <commit>는 브랜치 이름이 아니라 특정 커밋을 잠시 확인하거나 실험할 때 쓴다. 이 상태에서는 새 커밋을 만들어도 어느 브랜치 포인터도 자동으로 따라오지 않으므로, 결과를 보존하려면 나중에 브랜치를 따로 만들어야 한다.

문서 예시도 비슷하다. 특정 과거 커밋을 검토하다가 작업 가치가 생기면 그 자리에서 git switch -c new-branch로 이름을 붙여 이어 가면 된다.

--orphan는 어떤 상황에서 필요할까?

--orphan는 부모 없는 새 브랜치를 만든다. 첫 커밋이 새로운 루트가 되므로, 기존 저장소 이력과 분리된 별도 공개용 히스토리를 만들고 싶을 때 쓸 수 있다.

다만 일반적인 기능 개발에서는 드물다. 릴리스 산출물만 별도 브랜치로 공개하거나, 과거 이력을 노출하지 않은 채 현재 트리 비슷한 상태만 새로 시작해야 하는 특별한 경우에 가깝다.

이런 상황에서는 어떤 명령이 무난할까?

상황	권장 명령	이유
기존 브랜치로 단순 이동	git switch develop	브랜치 전환 의도가 가장 직접적으로 드러난다.
새 작업 브랜치를 만들고 시작	git switch -c feature/cache	생성과 전환을 한 번에 처리한다.
원격 브랜치에서 로컬 작업 시작	git switch bugfix/auth	하나의 remote에서만 이름이 보이면 자동 추적이 가능하다.
현재 변경을 유지하며 다른 브랜치 문맥으로 이동	git switch --merge release/1.2	겹치는 수정이 있으면 자동 stash 후 재적용을 시도한다.
과거 커밋을 잠깐 확인	git switch --detach HEAD~3	브랜치 포인터를 움직이지 않고 검토할 수 있다.

FAQ

Q. git switch만 있으면 git checkout은 더 이상 필요 없을까?

아니다. git switch는 브랜치 전환 전용이고, git checkout은 여전히 파일 경로 복원 같은 다른 모드를 포함한다. 최근 워크플로에서는 브랜치 전환은 switch, 파일 복원은 restore로 나누는 편이 더 명확하다.

Q. 로컬 변경이 있어도 무조건 전환되나?

아니다. 현재 변경이 손실될 위험이 있으면 기본 동작은 중단이다. 이때 --merge나 --discard-changes를 검토할 수 있지만, 둘 다 결과가 강하므로 현재 변경 범위를 먼저 확인해야 한다.

Q. 원격 브랜치 이름만 써도 항상 자동 추적이 되나?

아니다. 같은 이름의 remote-tracking branch가 정확히 하나일 때만 기본 추정이 단순하다. 여러 remote에 같은 이름이 있으면 명시적으로 remote를 적는 편이 안전하다.

정리

git switch의 선택 기준은 단순하다. 브랜치 이동이 목적이면 먼저 switch를 검토하고, 새 브랜치 생성은 -c, 임시 커밋 검토는 --detach, 현재 수정 유지 여부는 --merge와 --discard-changes로 나누면 된다.

한 줄 기준으로 줄이면 이렇다. 브랜치 전환은 git switch, 파일 복원은 git restore, 다기능 호환 명령이 꼭 필요할 때만 git checkout을 쓰는 구성이 실수를 줄이기 쉽다.

참고 자료

• Git Documentation: git-switch
• Git Documentation: git-checkout
• Git Documentation: git-branch