git stash의 의도 된 사용 사례는 무엇입니까?


143

분기 A에서 작업하고 분기 A에서 커밋을 준비하기 전에 갑자기 분기 B에서 작업해야하는 경우 A에 변경 사항을 숨기고 B를 체크 아웃하고 거기서 작업을 한 다음 A를 체크 아웃하고 숨김을 적용합니다.

A에서 작업하고 그날 작업을 중단하고 싶은 경우, 작업을 숨기고 다음날 적용해야합니까 (작업을 재개 할 때) 또는 그대로 두어야합니까? 커밋되지 않은 수정 된 파일은 작업 디렉토리? 보안상의 이점이있는 경우를 제외하고는이 경우 숨김을 사용해야하는 이유를 알 수 없습니다.

또 다른 시나리오 : 직장과 집에서 모두 일합니다. 집에 가고 싶을 때 커밋 할 준비가되지 않은 경우 작업을 숨겨서 GitHub에 푸시 한 다음 집에서 숨길 수 있나요?


3
회사 정책에 따라 크게 달라집니다. "수락 된"답변을 어떻게 선택 하시겠습니까?
데몬 페인터

1
말로 표현으로이 질문은 (I 힘내 사용해야 의견을 요청한다 방법 또는 폐쇄하거나 편집해야하므로 방법을?)합니다.
TylerH

답변:


161

Stash는 단지 편리한 방법입니다. git에서 브랜치는 매우 저렴하고 관리하기 쉽기 때문에 개인적으로 거의 항상 숨김보다 새 임시 브랜치를 만드는 것을 선호하지만 대부분 취향의 문제입니다.

내가 은닉하는 것을 좋아하는 곳은 마지막 커밋에서 무언가를 잊고 동일한 브랜치의 다음 커밋에서 이미 작업을 시작한 경우입니다.

# Assume the latest commit was already done
# start working on the next patch, and discovered I was missing something

# stash away the current mess I made
git stash save

# some changes in the working dir

# and now add them to the last commit:
git add -u
git commit --amend

# back to work!
git stash pop

2
당신이 그것을 풀면 당신이 추가 한 것이 누락 된 것이 은닉처에 병합됩니까? (난 여전히 타임 라인이 자식에서 작동하는 방법에 흔들리는 해요 - 내가 당신에게있는 거 덮어 역사를 가정 ??)
키키 쥬얼

@KikiJewell 팝 변경 사항은 인덱스에 적용되며 커밋되지 않습니다. 따라서 git stash pop두 번 수행하면 두 변경 세트 간의 차이를 잃게됩니다.
Mureinik

2017 년 10 월 말부터 Git 메일 링리스트에 대한 광범위한 논의가 있었으며, git stash save 명령은 기존 대안을 위해 더 이상 사용되지 않습니다 git stash push. 이에 대한 가장 큰 이유는 즉 git stash push선택된 보관 한 옵션을 소개합니다 pathspecs이 뭔가 git stash save지원하지 않습니다.
Krishna Gupta

39

세 문단에서 답을 나누겠습니다.

1 부:

git stash(커밋되지 않은 변경 사항을 "숨김"에 저장합니다. 참고 : 작업 트리에서 변경 사항을 제거합니다!)

git checkout some_branch(의도 한 분기로 변경-이 경우 some_branch)

git stash list (목록 숨김)

다음을 볼 수 있습니다.
stash @ {0} : WIP on {branch_name} : {SHA-1 of last commit} {last commit of you branch}
stash @ {0} : WIP on master : 085b095c6 modify for test

git stash apply (현재 분기의 작업 트리에 숨김 적용)

git stash apply stash@{12}(보관함이 많을 경우 어떤 보관함을 적용할지 선택할 수 있습니다.이 경우 보관함을 적용합니다 12)

git stash drop stash@{0}(숨김 목록에서 제거하려면-이 경우 숨김 0)

git stash pop stash@{1} (선택한 숨김을 적용하고 숨김 목록에서 삭제)

파트 2 :
이 명령을 사용하여 변경 사항을 숨길 수 있지만 반드시 필요한 것은 아닙니다.
숨김없이 다음날 계속할 수 있습니다.
이 명령은 변경 사항을 숨기고 다른 브랜치에서 작업하거나 코드를 구현하고 브랜치 및 커밋없이 사용자 지정 사례를 저장하지 않고 저장합니다!
나중에 은신처를 사용하여 더 나은 것을 확인할 수 있습니다.

파트 3 :
로컬 숨김 명령은 변경 사항을 숨 깁니다.
원격으로 작업하려면 커밋하고 푸시해야합니다.


10

주요 아이디어는

더티 작업 디렉토리에 변경 사항을 숨 깁니다.

따라서 Basicallly Stash 명령은 필요하지 않거나 현재 원하지 않는 일부 변경 사항을 유지합니다. 하지만 필요할 수 있습니다.

작업 디렉토리와 인덱스 의 현재 상태 를 기록하고 싶지만 깨끗한 작업 디렉토리로 돌아가고 싶을 때 git stash를 사용하십시오 . 이 명령은 로컬 수정 사항을 저장하고 HEAD 커밋 과 일치하도록 작업 디렉토리를 되돌 립니다.


7

다음 명령을 사용할 수 있습니다.

  • 커밋되지 않은 변경 사항을 저장하려면

    git stash

  • 저장된 보관함을 나열하려면

    git stash list

  • x가 0,1,2 인 커밋되지 않은 변경 사항을 적용 / 복구하려면 ...

    git stash apply stash@{x}

노트 :

  • 숨김을 적용하고 숨김 목록에서 제거하려면

    git stash pop stash@{x}

  • 숨김을 적용하고 숨김 목록에 유지하려면

    git stash apply stash@{x}


4

git stash작업 복사본 (스테이징 영역이 아님)에 변경 사항 이 있을 때 누르는 경우 git은 은닉 된 객체를 생성하고 스 태시 스택으로 푸시합니다 ( git checkout -- .그렇지만 변경 사항을 잃지 않을 것입니다). 나중에 스택 맨 위에서 튀어 나올 수 있습니다.


2

stash 명령은 마지막 커밋 이후에 변경 한 사항을 숨 깁니다. 귀하의 경우에는 다음 날 계속 작업 할 경우 숨길 이유가 없습니다. 나는 당신이 커밋하고 싶지 않은 변경 사항을 취소하는 데에만 숨김을 사용합니다.


2
아니요, git stash지점을 변경하지 않습니다. 특히 커밋 된 변경 사항을 "되 돌리지"않습니다. 파일에 대한 커밋되지 않은 변경 사항은 (임시적) 폐기됩니다. -까다로워 보일 수 있지만, 그런 단어들은 git의 맥락에서 매우 특별한 의미를 가지고 있습니다. 그것들을 정말로 섞어서는 안됩니다.
michas 2013

지적 해 주셔서 감사합니다. 나는 그에 따라 내 대답을 변경했습니다.
Severin

git에서 "branch"는 일련의 커밋으로 정의됩니다. git stash커밋을 건드리지 않으므로 분기를 전혀 수정하지 않습니다. 브랜치에서 아무것도 "제거"하지 않으며 어떤 방식으로도 "재설정"하지 않습니다. 분기는 동일하게 유지되며 작업 트리의 파일 만 변경됩니다. -완전히 다른 두 가지입니다.
michas

그것은 버리지 않고 변경 사항을 "숨겨 놓는다"! 힘내는 보관함에 대한 LIFO 구조를 유지하므로 보관함은 실제로 푸시이며 상단에서 튀어 나올 수 있습니다. "discard"라는 단어는 당신이 무엇이든 잃을 것이지만 당신은 잃지 않을 것임을 의미합니다.
gyorgyabraham

2

나는 StackOverflow가 의견 기반 답변을위한 곳이 아니라는 것을 알고 있지만 실제로는 숨김으로 변경 사항을 보류해야 할 때에 대해 좋은 의견을 가지고 있습니다.

실험적 변경 사항을 커밋하고 싶지 않습니다.

작업 영역 / 작업 트리를 변경할 때 병합, 푸시, 가져 오기 또는 가져 오기와 같은 분기 기반 작업을 수행해야하는 경우 깨끗한 커밋 지점에 있어야합니다. 따라서 작업 영역 변경 사항이있는 경우이를 커밋해야합니다. 하지만 그들을 저지르고 싶지 않다면 어떨까요? 실험적이라면 어떨까요? 커밋 기록에 원하지 않는 것이 있습니까? GitHub로 푸시 할 때 다른 사람이 보지 않기를 원하는 것이 있습니까?

하드 리셋으로 로컬 변경 사항을 잃고 싶지 않습니다.

이 경우 하드 리셋을 수행 할 수 있습니다. 그러나 하드 리셋을 수행하면 모든 로컬 작업 트리를 잃게됩니다. 변경 사항이 마지막 커밋 당시의 위치로 덮어 쓰여지고 모든 변경 사항 되므로 모든 변경 사항을 잃게됩니다.

따라서 '언제 숨겨야 하는가'에 대한 대답은 동기화 된 작업 트리 / 인덱스 / 커밋을 사용하여 깨끗한 커밋 지점으로 돌아 가야하지만 로컬 변경 사항을 잃고 싶지 않을 때입니다. 과정. 변경 사항을 은닉처에 보관하면 괜찮습니다.

그리고 일단 당신이 당신의 은닉을 완료 한 다음 병합, 풀, 푸시를 완료하면 팝을 숨기거나 적용 할 수 있습니다. 시작했던 곳으로 돌아갑니다.

Git 숨김 및 GitHub

GitHub는 지속적으로 새로운 기능을 추가하고 있지만 현재로서는 거기에 은닉처를 저장할 수있는 방법이 있습니다. 다시 말하지만, 숨김의 아이디어는 로컬 및 비공개라는 것입니다. 당신의 워크 스테이션에 물리적으로 접근하지 않고서는 아무도 당신의 보관함을 들여다 볼 수 없습니다. git reflog가 비공개이고 git log가 공개되는 것과 같은 방식입니다. GitHub로 푸시 된 경우 비공개가 아닐 것입니다.

한 가지 트릭은 작업 공간의 차이를 확인하고 git 저장소에서 차이를 확인한 다음 커밋 한 다음 푸시하는 것입니다. 그런 다음 집에서 당겨서 차이를 확인한 다음 긴장을 풀 수 있습니다. 그러나 그것은 그 결과를 얻기위한 꽤 지저분한 방법입니다.

git diff > git-dif-file.diff

은닉처를 터 뜨리다

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.