한 지점에서 다음 지점으로 변경 사항을 이동할 수 있다고 생각하지만 그게 체리 따기의 목적이며 변경 사항을 커밋하지 않는 경우 변경 사항을 이동해서는 안됩니까?
때때로 잘못된 지점에 잘못된 숨김을 적용하여이 질문에 대해 궁금해했습니다.
답변:
앞서 언급했듯이 "분기 별 숨김"을 원하면 기존 분기에서 분기 된 새 분기를 정말로 원합니다.
또한 숨김을 사용하면 작업중인 브랜치로 가져올 수 있다는 사실 외에도 모든 것을 커밋하기 전에 브랜치 를 전환 할 수 있습니다 . 이것은 작업 복사본 을 체리 따기만큼 일반적인 의미에서 체리 따기에는 유용하지 않습니다 .
F.ex. 기능 브랜치에서 작업하는 동안 해당 브랜치와 관련이없는 코드에서 사소한 버그 나 외관상의 불순물을 종종 발견합니다. 글쎄, 나는 바로 그것들을 고친다. 커밋 할 때가되면 관련 변경 사항을 선택적으로 커밋하지만 수정 사항과 화장품은 적용하지 않습니다. 대신 나는 그것들을 숨겨서 안정에 대한 마이너 수정 브랜치로 전환 할 수 있습니다. 그런 다음 스 태쉬를 적용하고 각 마이너 수정을 개별적으로 커밋 할 수 있습니다. (문제의 변경 사항에 따라 일부를 다시 숨기고 다른 기능 브랜치로 전환하여 적용 합니다 .)
이를 통해 작업 할 때 프로그래밍 모드에 깊이 들어갈 수 있으며 코드의 적절한 라이브러리에 대해 걱정할 필요가 없습니다. 그런 다음 정신적 휴식을 취하면 돌아가서 변경 사항을 올바른 선반으로 신중하게 분류 할 수 있습니다.
숨김이 전역 적이 지 않은 경우 이러한 유형의 워크 플로는 수행하기 훨씬 더 어려울 것입니다.
As mentioned, if you want a “per-branch stash,” you really want a new branch forking off from the existing branch.. 특히 같은 프로그램의 두 가지 버전을 자주 전환하고 전체를 실행하는 make데 10 분이 걸립니다. 빌드 된 바이너리를 분기별로 숨길 수 있다면 매우 좋을 것입니다. 그리고 저는 확실히 로그 나 분기에 바이너리를 원하지 않습니다.
gitk --all"은 (는) 더 이상 첫 번째 숨김을 표시하지 않습니다. 나는 그것이 망가질 것이라고 생각했다. 두 번째 지점에서 작업을 마치고 나서 그 보관함을 뜯어 냈습니다. 그 후 업데이트 된 " gitk --all"이 (가) 원래의 은닉처를 다시 표시했습니다.
브랜치에서 실행되는 "숨김"을 원한다면 현재 브랜치의 새 브랜치에 변경 사항을 저장하기 위해 이와 같은 작업을 수행하십시오.
git checkout -b new_stash
git commit -a -m "stashed changes"
은닉을 취소하려면
git reset HEAD^
git branch -d new_stash
git stash는 변경 사항을 더티 트리로 가져올 수 있기 때문에 특히 유용합니다. 즉, 뛰어난 편집 내용이 있고
git pull
그리고 당신은 할 수 없습니다, 당신은 당신의 변경 사항을 숨기고, 숨긴 다음 적용 할 수 있습니다
git stash
git pull
git stash apply
git stash clear
이것이 도움이 되었기를 바랍니다!
make해당 브랜치 에서 실행 된 결과로 생성 된 바이너리 인 경우에는 어떻게됩니까? (분기 별 숨김은 다음에 해당 분기에서 증분 빌드를 수행 할 때 시간을 절약 할 수 있지만 확실히 바이너리를 인덱스에 추가하고 싶지 않습니다.)
git-stash는 아직 체크되지 않은 변경 사항을 현재 체크 아웃 된 브랜치가 아닌 다른 브랜치로 옮기는 데 가장 유용합니다.
예를 들어-나는 종종 버그 수정 브랜치에서 간단한 변경을하고 있음을 발견합니다. 제가 작업중인 변경 사항이 처음에 예상했던 것보다 더 복잡하다는 것을 알게되었습니다. Git-stash는 변경 사항 집합을 다른 분기로 이동하는 가장 쉬운 방법입니다.
git stash-here누군가?