접니다. checkout 명령어를 지양해야 한다는 떠도는 소문을 듣고 명령어를 정확히 사용하고자 블로깅하게 되었습니다. (끊임없이 업데이트하는 개발자ㅇㅅㅇ!) 또 공식문서/블로그를 먼저 살펴보는 습관을 기르고 자 깃허브 블로그에 들어갔는데요. 2019년도에 출시된 Git 2.23부터 checkout의 기능을 분리했고, 2023년인 현재는 2.42 버전까지 나왔으니 더욱더 산업군에 관심을 기울여야겠다고 생각했습니다. (git 공식 한국어 가이드북에는 checkout으로 설명되어 있어 반영이 안된 듯하네요.)
switch와 restore 명령어로 쪼개진 checkout 책임 분리
checkout 명령어는 두 가지 기능(1. 기존/새로운 브랜치 전환과 2. 작업 트리 파일 복원(파일의 수정내용 복원))으로 사용되어 의도치 않게 많은 책임을 감당하고 있었습니다. 그래서 책임을 정확히 분리하고 자 switch와 restore 명령어가 생겨났고, 사용법은 기존 checkout과 비슷해 편리함까지 잡았네요. reset의 일부분 명령어도 restore 기능에 들어왔다고 합니다.
- switch -> checkout의 "기존/새로운 브랜치 전환"
- restore -> checkout의 "작업 트리 파일 복원" (파일의 수정내용 복원)
//기존
git checkout "브랜치 이름" //"브랜치 이름"으로 전환
git checkout -b "브랜치 이름" //"브랜치 이름"으로 새브랜치를 만들고 전환
git checkout -- "파일 이름" //파일의 수정내용 복원
git reset HEAD "파일 이름" //git add를 통해서 수정 내용을 stage에 이미 넣었을 때 이를 다시 뺄때
//Git 2.23 이후
git switch "브랜치 이름" //"브랜치 이름"으로 전환
git switch -c "브랜치 이름" //"브랜치 이름"으로 새브랜치를 만들고 전환
git restore "파일 이름" //파일의 수정내용 복원
git restore --staged "파일 이름" // stage 에 있는 수정 내역 복구개발이 전부 그렇듯 개념들을 정확히 파악하고 상황에 맞춰 적합한 명령어를 사용하는 것이 바람직하다는 생각이 들었습니다. 그리고 git checkout -b "브랜치 명"과 git branch "브랜치명"을 헷갈렸는 데 이번기회에 확실히 알게 되어 기분이 좋습니다. 히히
- 브랜치 생성 === git branch "브랜치명"
- 브랜치 생성 후 생성된 브랜치로 변환 === git checkout -b "브랜치 명"
정리
- 책임이 많은 checkout보다 브랜치 전환할 때는 switch를, 파일의 수정내용 복원할 때는 restore를 쓰자!
출처
https://github.blog/2019-08-16-highlights-from-git-2-23/
Highlights from Git 2.23
Take a look at some of the new features in the latest Git release.
github.blog
https://github.blog/2023-08-21-highlights-from-git-2-42/
Highlights from Git 2.42
Another new release of Git is here! Take a look at some of our highlights on what's new in Git 2.42.
github.blog
Git - 브랜치란 무엇인가
3.1 Git 브랜치 - 브랜치란 무엇인가 모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와
git-scm.com
(Q. 단일 책임 원칙을 지키는 고자 하는 걸까요? 단일 책임 원칙은 정확히 무어냐!)
reset 명령어는 언제 쓰임? reset와 restore의 차이는? )
