Stash

Violet_Evgadn·2023년 9월 7일
0

Git

목록 보기
26/33

Stash

Stash란?

Git Stash는 현재의 작업 내용을 임시 저장하는 기능이다.

현재의 작업물을 잠깐 서랍에 넣어두고 특정 커밋으로 이동하여 작업을 완료한 뒤 서랍에 넣어둔 작업물을 다시 꺼내 쓸 수 있게 해주는 기능이라고 이해하면 편하다.

그렇다면 이러한 Stash는 왜 필요할까?

현업에서 일을 하다 보면 항상 내가 하고 있는 일이 완료된 뒤 다음 일을 수행한다는 보장이 없다.
A라는 기능을 개발하고 있는데 이 A라는 기능을 위해 변경 파일 10개가 로컬에 생성되어 있고 이 상황에서 현재 운영되고 있는 서비스에 핫픽스 해야 하는 버그가 생겼다고 가정하자.
이 버그를 해결하려면 main 브랜치로 이동해야 할 텐데 만약 main 브랜치로 이동(checkout)한다면 A 기능을 위한 10개의 변경 파일이 없어질 것이다.
그렇다고 10개의 변경 파일을 커밋 하기엔 아직 파일들이 미완성된 파일들이기에 쓰레기 커밋을 생성하게 될 것이다.

이 경우 git stash를 통해 10개의 변경 파일들을 임시 저장시켜 놓은 뒤 main 브랜치에 checkout하여 작업을 수행하면 된다.
이렇게 된다면 버그를 핫픽스 한 뒤 원래 작업하던 브랜치로 돌아와 Stash에 저장한 임시 파일을 불러옴으로써 계속해서 A 기능에 대한 작업을 수행할 수 있을 것이다.


IntelliJ를 활용한 Stash

Git Stash 같은 경우 CLI를 통해 활용하는 경우가 더 많다.
필자도 Git Stash를 CLI로만 활용하다 이번 정리를 위해 처음 IntelliJ에서 활용해 보았다.
IntelliJ에서의 활용법은 한 번 훑어만 보고 CLI를 통한 Stash 활용법에 조금 더 집중하는 것을 추천한다.

Stash 생성

0. Stash 테스트를 위한 변경 사항 생성


Stash가 제대로 될까?라는 문구를 추가하였다.
(절대로 Commit 하지는 말자. Stash는 "커밋 하지 않은 변경사항"들을 저장하는 기능이다)

1. Git > Uncommitted Changes > Stash Changes 선택

2. Create Stash

Message에 Stash를 구별할 수 있을만한 문구를 기입하자.
어떤 기능을 개발하고 있던 중인지 입력하는 것을 추천한다.

추가했던 문구가 삭제된 것을 볼 수 있다.
현재 상황은 마지막 Commit의 상황이기 때문에 마음 놓고 다른 브랜치에 Checkout 하거나 다른 작업을 수행할 수 있다.

Stash 가져오기

작업이 완료되어 다시 Stash에 저장했던 변경 사항을 가져오고 싶다.
어떻게 가져올 수 있는지 알아보자.

3. Git > Uncommitted Changes > Unstash Changes 선택

4. 원하는 Stash 선택 > Apply Stash 선택

Stashes란에 이전에 생성했던 stash가 존재하고 있음을 볼 수 있다.

View는 Stash가 저장한 변경 사항 보기, Drop은 Stash 삭제, clear은 Stash 목록 전부 초기화를 의미한다.
Pop stash 같은 경우 CLI Stash를 설명할 떄 조금 더 자세히 설명하겠다.

삭제되었던 Stash가 제대로 될까?문구가 다시 불러와졌음을 볼 수 있다.


CLI를 통한 Stash

git stash [Option]

Index

Git Stash를 공부하기 앞서 Index에 대해 알고 갈 필요가 있다.
IntelliJ GUI에서 Stash 목록을 보면 앞에 stash@{0}이라는 이상한 문구가 있음을 알 수 있다.

여기에서 0에 해당하는 값({} 사이에 있는 수)이 바로 Index이다.
최근에 생성된 Stash일수록 Index가 작고 오래될수록 Index가 커진다.
(즉 가장 최근에 생성된 Stash Index는 0일 것이다)

추가로 저장한 Stash를 불러올 때 특정한 언급이 없다면 stash@{0}, 즉 가장 최근 Stash를 불러오게 된다.

Stash 저장 & 조회

git stash, git stash save <Message>

git stashgit stash save 모두 현재 변경된 내용들을 Stash를 활용하여 저장하는 명령어이다.

둘의 차이점은 "Stash의 이름을 지정할 수 있는가"여부이다.

git stash를 사용할 경우 생성할 Stash의 이름을 지정할 수는 없다.
만약 이름을 지정하기 위해선 git stash save <Stash Message> 명령어를 활용하여 Stash 저장을 수행해야 한다.

git stash save를 통해 Stash Message 지정 없이도 변경사항을 저장할 수는 있지만 이렇게 사용할 거면 git stash를 활용하는 것이 더 편할 것이다.

git stash --keep-index

IntelliJ에서 stash 저장을 수행할 때 Keep Index라는 체크박스가 있었는데 이 체크박스가 --keep-index 옵션을 의미한다.

(위에서 봤듯) Stash를 저장한다면 변경사항들이 모두 삭제되고 마지막 Commit 상태로 원복 된다.
하지만 --keep-index를 사용하면 변경사항을 Stash에 저장하더라도 변경사항들이 모두 Working Directory에 남아 있게 된다.

git stash list

Stash 목록을 조회하는 명령이다.

재미있는 것이 git stashgit stash save <Message>를 통해 생성한 Stash가 목록에 조금 다르게 표시된다는 것이다.
(On main : , WIP on main : 으로 표시됨)

git stash show [stash@{index}]

stash@{index}에 해당하는 Stash에 저장된 내용을 확인하는 명령어이다.

만약 stash@{index}가 없다면 가장 최근 Stash(stash@{0})에 저장된 내용을 확인한다.

git stash-rename [stash@{index}]

지정한 Stash의 Message(Stash 이름)을 수정하는 명령어이다.

Stash 가져오기

git stash apply [stash@{index}]

git stash apply는 Stash List에서 Stash를 가져와 Working Directory에 반영하는 명령어이다.

git stash apply로 Stash를 가져오면 Stash List에 해당 Stash는 삭제되지 않고 그대로 유지된다.

만약 Stash를 가져온 뒤 해당 Stash를 Stash List에서 삭제하고 싶다면 아래에서 배울 git stash pop으로 변경사항을 가져오거나 git stash apply 이후 git stash drop을 활용하여 Stash List에 Stash를 삭제하는 과정이 추가 수행되어야 한다.

git stash pop [stash@{index}]

git stash pop은 가장 최근에 생성된 Stash를 가져오는데 이때 가져온 Stash를 Stash List에서 자동으로 삭제한다.

pop 이후 [stash@{index}]를 사용한다면 지정한 Stash를 Stash List에서 가져와 Working Directory에 변경사항을 적용한 뒤 가져온 Stash를 리스트에서 삭제한다.

(개인적으론 git stash apply보다 git stash pop을 더 많이 활용하는 것 같다. Stash를 한번 가져왔다면 굳이 해당 Stash를 다시 사용할까라는 생각이 있기 때문이다)

git stash drop [stash@{index}]

지정한 Stash를 제거하는 명령어이다.
만약 [stash@{index}]가 없다면 최근 생성된 Index([stash@{index}])를 삭제한다.

git stash clear

Stash List에 있는 모든 Stash들을 삭제한다.

git stash pop --index | git stash apply --index

Stash를 가져올 때 --index 옵션을 사용할 수 있다.

Stash를 공부하며 아래와 같은 의문점이 생겼다면 Git 공부를 제대로 하고 있는 것이다.
"Stash가 Commit 되지 않은 변경 사항을 임시 저장한다는 것은 알겠는데, 과연 Staging된 변경 사항은 어떻게 처리할까?"

결론부터 말하자면 기본적으로 Stash는 Staging 관계없이(파일 상태 관계없이) Stash에 저장된 모든 변경사항들을 가져온다.

하지만 변경 사항을 가져올 때 Staging 되어 있는 상태까지 가져오고 싶을 수 있다.
이때 활용하는 것이 바로 --index 옵션이다.

--index 옵션을 사용할 경우 Staging 되어 있던 변경사항들은 그대로 Staging 된 상태로 불러와진다.
단, 변경사항이 새로 추가된 파일이라면 해당 파일은 --index 옵션 없이도 바로 Staging된 상태로 불러오게 된다.

(뇌피셜)
개인적인 생각으로는 새 파일은 Staging된 상태로 불러오는 것이 편의성 때문이 아닐까라고 생각한다.

만약 새로운 파일이 Staging된 상태가 아니라면 Untracked 상태라는 것인데 Untracked 상태일 경우 GUI를 통해 Commit하거나 git addcommit을 동시에 해주는 명령어를 활용할 때 추가된 파일이 누락될 위험성이 존재하기 때문이다.

profile
혹시 틀린 내용이 있다면 언제든 말씀해주세요!

0개의 댓글