Switch & Restore

switch

Git Switch는 브랜치를 변경하는 명령어이다.

git switch 명령을 수행하면 브랜치가 이동되는데 이 과정에서 먼저 .git/HEAD 값이 원하는 브랜치의 커밋 ID 값으로 변경되는 과정이 수행된다.
앞에서 말했듯 .git 폴더는 로컬 저장소로 여러 가지 파일을 가지고 있다. 이 중 HEAD 값은 현재 Git 시스템이 가리키고 있는 커밋 ID를 의미한다.
브랜치 이동은 Git HEAD를 원하는 브랜치의 최신 커밋을 가리키게 하는 동작이기 때문에 왜 .git/HEAD 값만 변경함으로써 브랜치가 변경되는지도 이해할 수 있을 것이다.

이후 git switch 명령은 git reset --hard 명령어를 통해 Stage 및 Working Tree 작업 내용을 HEAD가 가리키는 내용으로 초기화시켜준다.
만약 Staging 된 변경 사항들을 유지시킨다면 HEAD는 다른 브랜치를 가리키고 있는데 정작 내용물은 기존 브랜치의 작업물을 가지고 있는 어지러운 상황이 될 수 있다.

정리하자면 git switch 명령은 .git/HEAD 값을 변경시켜 HEAD의 값을 원하는 브랜치의 최신 커밋 ID 값으로 변경하고 git reset --hard 명령어를 통해 Stage 및 Working Tree 작업 내용을 초기화시켜주는 작업이 수행되는 것이다.
(따라서 git switch를 수행하면 Working Directory의 작업물도 해당 브랜치의 작업물로 변환되는 것이다)

restore

git restore는 git의 파일 조작(특정 커밋으로 되돌리기, Unstaging 시키기 등)을 위해 만들어진 명령어이다.

조금 더 간단히 말하자면 몇 개의 파일들을 특정 커밋이 가지고 있는 파일의 상태로 변경하는 명령어이다.
반대로 이를 조금 전문적으로 말하면 특정 파일을 워킹 트리에 존재하는 상태 중 하나로 복원해 주는 명령어라고 할 수 있다.

그렇다면 왜 2개를 한번에 설명했을까?

바로 git restore와 git switch가 git checkout을 대체하기 위해 나온 명령어이기 때문이다.

git checkout = git restore + git switch

사실 이전까지 브랜치를 이동하거나 특정 파일을 복원할 때 git checkout을 사용하는 것이 더 일반적이었을 것이다.

• 브랜치 이동 : git checkout <브랜치명>

• 파일 복원 : git checkout <커밋 ID> <파일 이름>

하지만 git 시스템이 계속해서 업그레이드되면서 점차 git checkout이 가진 기능이 너무 많아졌다.
이렇게 한 명령어가 너무 많은 기능을 가지는 것은 객체 지향적으로 봤을 때 SRP(한 클래스는 하나의 책임만 가져야 한다)라는 원칙에 위배되고 잘못하면 God Object와 같은 잘못된 설계의 명령어가 될 수도 있다.

따라서 Git 시스템은 여러 버전 업그레이드를 거치며 checkout이라는 명령어를 복원 역할의 restore와 브랜치 이동의 switch로 쪼갰고 이를 나타내고자 관계도 없을 것 같아 보이는 2개 명령어를 한 Section에서 설명하게 되었다.

restore

• git restore [File Name] : 지정한 파일을 HEAD가 가리키고 있는 Commit 상태로 복구

• git restore --source [커밋 ID] [File Name] : 특정 파일을 특정 Commit 상태로 복구

• git restore --staged [File Name] : Staging된 파일을 다시 Unstaging 시킴

  • git add 명령어로 Staging Area에 등록된 파일을 다시 Staging Area에서 내리는 동작을 수행한다.

switch

• git switch [Branch Name] : 지정한 브랜치로 이동

• git switch -c [Branch Name] : 브랜치를 새로 생성한 뒤 생성한 브랜치로 이동

  • git checkout -b [Branch Name] 명령어와 동일하게 동작한다.