git checkout <commit-hash>

HEAD를 해당 커밋으로 이동시킨다. 명령어 실행 시 HEAD가 분리된 상태라는 메시지가 출력된다.

브랜치는 언제나 해당 브랜치의 최근 커밋을 가리키고 HEAD는 그 브랜치를 가리키게 된다. 일반적으로 HEAD는 커밋이 아닌 특정 브랜치를 참조하게 된다.

하지만 해당 명령어를 통해서 HEAD가 특정 커밋을 참조하도록 바꾼다. 원래 브랜치를 참조하던것이 커밋을 참조하게 되었으므로 분리된 상태가 된 것이다.

이를 통해 이전 커밋을 참조할 수 있다.

다시 브랜치로 돌아가려면 switch 명령어로 돌아가면 된다. "git switch -" 입력 시 현재 브랜치의 최상단으로 이동한다.

HEAD가 분리된 상태에서도 브랜치를 새로 생성시킬 수 있다.

과거의 커밋으로 돌아가서 프로토타입 작성 등의 새로운 작업을 시작할 때 매우 유용하게 사용할 수 있을 것 같다.

git checkout HEAD <file-name>

커밋 참조를 이용해서 작업 영역의 변경 사항을 한번에 초기화 하는 방법이다.

무언가 열심히 작업을 하다가 문제가 생기거나 마음에 안들어서 초기화 할때 사용하면 된다.

파일 이름을 적어주면 해당 파일만 마지막 커밋 내용으로 덮어씌워진다.

HEAD 대신 -- 을 입력해도 된다.

git restore

checkout이 너무 많은 기능을 수행하기 때문에 독립시켜 만든 명령어이다.

git checkout HEAD <file-name> == git restore <file-name> 이다.

git restore --source <commit-hash> <file-name> : 특정 커밋의 파일로 변경한다.

git restore --staged <file-name> : 스테이지에 등록된 파일을 다시 작업 영역으로 되돌린다.

git restore 명령어는 git status에서 사용법을 알려주기도 한다.

git reset

저장소를 특정 커밋으로 재설정한다.

일반 재설정과 하드 재설정이 존재한다.

일반 재설정 / git reset <commit-hash>

위와 같이 잘못된 커밋이 존재할 경우 해당 명령어로 커밋만 삭제할 수 있다.

"커밋만" 삭제한다는 점을 주의해야한다. 변경된 사항은 여전히 작업 영역에 남아있다.

HEAD부터 <commit-hash> 직전까지의 범위를 모두 삭제한다.

 

잘못된 브랜치에서 커밋을 했을 때 유용하게 사용할 수 있다.

커밋을 삭제하고 남아있는 변경사항을 정상적인 브랜치에서 다시 커밋을 하면 된다.

 

 

하드 재설정 / git reset --hard <commit-hash>

--hard 플래그 하나가 추가된 형태이다. 커밋을 삭제하는것은 동일하지만 작업의 변경사항까지 모두 삭제한다.

일반 재설정 이후 restore로 작업 영역의 변경사항을 취소한것과 마찬가지이다.

reset은 브랜치 기준으로 작동한다.

git revert <commit-hash>

reset과 기능이 매우 유사하다. reset은 커밋을 제거하고 브랜치 포인터를 뒤로 이동시키는 반면에 revert는 새로운 커밋을 만들어서 이전 커밋의 변경 사항을 취소한다.

결과적으로 커밋을 취소(되돌리는것)하는것은 동일하지만 커밋을 삭제하느냐 남겨두느냐의 차이가 있다.

병합 커밋을 실행할때처럼 명령어 실행 시 충돌을 처리해야 할 수도 있다.

revert를 사용하는 이유는 협업 때문이다.

설령 잘못된 커밋이더라도 다른 사람들이 작업하고 있는 커밋이라면 reset으로 커밋을 제거했을 때, 다른 사람들이 가지고 있는 기록을 취소하는 것이기 때문에 심각한 문제가 발생될 수 있다.

커밋 실수를 했을 때 다른 사람들과 공유되지 않았다는 것이 확실할때는 reset을 사용하는 것이 좋고 다른 사람들과 공유중인것이 확인됐을 때는 revert를 사용해야 한다.

요약

• git restore : 작업 영역의 수정 사항이나 스테이징을 취소한다.
• git reset : 커밋을 취소한다. (커밋 삭제)
• git revert : 커밋을 복구한다. (새로운 커밋 생성)

reset과 revert는 결과는 동일하지만 과정이 다르다.

git stash (=git stash save)

커밋되지 않은 변경사항을 저장하고 변경사항들을 모두 초기화시킨다.

내용이 삭제되는것이 아니라 스태시에 저장된 상태이다.

git stash pop

스태시에 저장된 가장 최근 목록을 가져오고 삭제한다.

git stash apply

방식은 pop과 동일하다. 단, 스태시가 삭제되지 않고 남기때문에 여러 브랜치에서 동일한 내용을 적용할 수 있다.

git stash list

스태시는 여러개 등록이 가능하다.

스태시 아이디를 통해서 특정 스태시를 적용시킬 수 있다.

스태시를 적용하고 바로 다른 스태시를 적용하려고 하면 위와 같이 에러가 발생한다.

작업 내용이 덮어씌워지기 때문에 에러가 발생하고 병합 되기전에 커밋이나 스태시를 하라고 한다.

git stash drop

특정 스태시를 삭제시킬 수 있다.

git stash clear

모든 스태시를 삭제한다.

git diff

스테이지에 등록되지 않은 작업 영역의 변경사항을 모두 나열한다.

a는 커밋된 파일, b는 작업 영역의 파일이다.

git diff HEAD

마지막 커밋이 실행된 이후의 변경사항을 모두 나열한다.

마지막 커밋 이후 변경 사항을 스테이지에 올리지 않은 상태라면 git diff, git diff HEAD 둘다 같은 결과를 출력한다.

하지만 변경 사항을 스테이지에 올린다면 git diff는 아무것도 출력되지 않지만 git diff HEAD는 결과가 출력된다.

git diff --staged (--cached)

스테이지에 등록된 변경사항만을 나열한다.

git diff branch1 branch2 (branch1..branch2)

두 브랜치를 비교하여 변경사항을 모두 나열한다.

a, b는 브랜치 입력 순서에 따라 매칭된다. 위와 같은 경우는 a는 branch1, b는 branch2이다.

git diff commit1 commit2 (commit1..commit2)

두 커밋을 비교하여 변경사항을 모두 나열한다.

마찬가지로 a, b는 커밋 입력 순서에 따라 매칭된다.

* HEAD는 단순히 마지막 커밋을 가리키는 레퍼런스이다. 그래서 git diff HEAD HEAD~1 실행시 마지막 커밋과 그 부모커밋을 비교하는 명령어가 된다.

git diff <file-name1> <file-name2> <..>
git diff --staged <file-name>
git diff HEAD <file-name>
git diff branch1..branch2 <file-name>
git diff commit1..commit2 <file-name>

위와 같이 특정 파일에 대한 변경사항만 확인할 수도 있다. 동시에 여러 개의 파일도 가능하다.

병합의 2가지 원칙

• 특정 커밋이 아닌 브랜치를 병합한다.
• 항상 현재 HEAD 브랜치에 병합한다.

HEAD

브랜치 생성에 앞서 알아야 할 개념.

각 브랜치는 브랜치 레퍼런스를 가지고 있으며 HEAD는 이 브랜치 레퍼런스를 가리키면서 전환하게 된다. 일종의 포인터이다.

git branch

저장소에 존재하는 브랜치 목록을 보여준다.

-d, --delete : 브랜치를 삭제한다. checkout했거나 현재 보고있는 브랜치는 삭제가 안되므로 다른 브랜치로 이동해서 삭제해야 한다.

-m, --move : 브랜치의 이름을 재설정한다. 이름을 변경하려는 브랜치로 이동해야 한다.

git branch <branch-name>

HEAD가 현재 가리키는 브랜치에 새 브랜치를 생성한다.

git switch

브랜치 간에 이동을 한다. (HEAD가 가리키는 레퍼런스 전환)

-c : 브랜치 생성과 이동을 동시에 한다.

git checkout

브랜치 간에 이동하거나 작업 트리를 복구시키기 위해 사용된다.

# 둘은 서로 동일하다
git switch -c main
git checkout -b main