답변:
몇 가지 옵션이 있습니다.
선반 항목을. 이렇게하면 변경 사항이 저장되고 작업 디렉토리에서 제거되므로 분기를 계속할 수 있습니다. 변경 세트를 생성하지 않습니다.
hg shelve --all --name "UnfinishedChanges"
hg unshelve --name "UnfinishedChanges"
업데이트 / 편집 : 최신 버전의 수은을 사용해야 할 수 있습니다.
hg shelve -n "UnfinishedChanges"
hg unshelve "UnfinishedChanges"
여전히을 --name대신 사용할 수 -n있지만 수은은 --name더 이상 좋아하지 않는 것 같습니다 . 또한 --all더 이상 필요하지 않으며 실제로 수은이 그 이상을 두려워 할 것입니다.
패치 는 mq. 이것은 어떤 측면에서 선반에 비해 너무 다르지 않지만 다르게 작동합니다. 최종 결과는 동일하며 변경 사항이 제거되며 나중에 선택적으로 다시 적용 할 수 있습니다. 푸시되면 패치는 논리적 변경 세트이며, 팝되면 다른 곳에 저장되며 변경 세트 기록의 일부가 아닙니다.
hg qnew "UnfinishedWork"
hg qrefresh
hg qpop
hg qpush "UnfinishedWork"
로컬로 커밋하고 이전 변경 세트로 업데이트하고 계속 작업하고 익명 분기 (또는 여러 헤드)를 사용합니다. 그런 다음 변경하려면 헤드를 병합 할 수 있습니다. 변경을 원하지 않는 경우 변경 세트를 제거 할 수 있습니다 .
hg commit -m"Commiting unfinished work in-line."
hg update -r<previous revision>
hg strip -r<revision of temporary commit>
명명 된 분기에 커밋합니다. 그러면 워크 플로가 옵션 3 (준비되면 병합 또는 제거)과 동일하게됩니다.
hg branch "NewBranch"
hg commit -m"Commiting unfinished work to temporary named branch."
hg update <previous branch name>
개인적으로 저는 변경 세트를 제거하거나 부분 코드를 체크인하는 것을 신경 쓰지 않기 때문에 옵션 3 또는 4를 사용합니다 (결국 푸시되지 않는 한). 필요한 경우 다른 사용자로부터 로컬 변경 세트를 숨기기 위해 새로운 단계 항목 과 함께 사용할 수 있습니다.
또한 rebase병합으로 코드 기록에 아무것도 추가하지 않는 병합을 피하기 위해 명령을 사용하여 변경 집합을 이동합니다. 병합은 중요한 분기 (예 : 릴리스 분기) 간의 활동이나 수명이 더 긴 기능 분기의 활동을 위해 저장하는 경향이 있습니다. histedit변경 세트를 압축하는 데 사용 하는 명령 도 있습니다. 여기서 "수다 스러움"이 값을 감소시킵니다.
패치 대기열도이를 수행하는 일반적인 메커니즘이지만 스택 의미 체계가 있습니다. 패치를 푸시하고 팝하지만 스택의 다른 패치 "아래"에있는 패치는 그 위에있는 패치도 푸시해야합니다.
경고 , 이러한 모든 옵션과 마찬가지로 보류 / 대기 / 분기 한 임시 변경 사항 이후 파일에 더 많은 변경 사항이있는 경우 보류 해제 / 밀기 / 병합시 병합 해결이 필요합니다.
--all이 인식되지 않습니다. 어쨌든 모든 변경 사항을 보류하는 것은 기본 동작입니다.
개인적으로 지금까지 게시 된 답변이 마음에 들지 않습니다.
shelve빠른 수정을 위해 사용 합니다 (내가 잘못된 지점에 있다는 것을 알게되면 커밋되지 않은 변경 사항을 다른 지점으로 옮기기 위해). 당신은 며칠에 대해 이야기하고 있습니다.mq이런 평범한 상황에는 너무 복잡 하다고 생각합니다가장 좋은 방법은 변경 사항을 시작하고 거기에서 작업하기 전에 변경 세트로 돌아가서 변경 사항을 커밋하는 것입니다. 몇 가지 사소한 문제가 있습니다. 설명하겠습니다.
변경 세트 A가 있다고 가정합니다. 변경을 시작하는 것보다. 이 시점에서 잠시 따로 보관 해 두십시오. 먼저 작업을 수행하십시오.
hg ci -m "Working on new stuff"
원하는 경우 나중에 쉽게 돌아올 수 있도록 책갈피를 추가 할 수 있습니다. 저는 항상 익명의 지점에 대한 책갈피를 만듭니다.
hg bookmark new-stuff
이러한 수정 이전의 변경 집합으로 돌아 가기
hg update A
여기에서 작업하고 변경 세트 C를 생성합니다. 이제 2 개의 헤드 (B 및 C)가 있으므로 푸시하려고 할 때 경고가 표시됩니다. 해당 분기의 헤드를 지정하여 하나의 분기 만 푸시 할 수 있습니다.
hg push -r C
또는 new-stuff분기 단계 를 비밀로 변경할 수 있습니다 . 비밀 변경 세트는 푸시되지 않습니다.
hg phase -r new-stuff --secret --force
mq 너무 복잡 하다고 생각 하지만, 이것을 포함하여 충분히 넓은 범위를 가지고있어서 그것에 유창 해지기 위해 시간을 투자하는 동안 가치가 있습니다.
커밋되지 않은 로컬 변경 사항을 유지하려면 가장 쉬운 방법은 패치 파일로 저장하는 것입니다.
hg diff > /tmp/`hg id -i`.patch
이전 상태로 돌아 가야 할 때 :
hg up <REV_WHERE_SAVED>
hg patch --no-commit /tmp/<REV_WHERE_SAVED>.patch
/tmp하고 hg id -iWindoze에서도 작동합니다.
hg up거기에 필요하지 않습니다.
리포지토리를 여러 번 복제 할 수 있습니다. 나는 루트 클론을 갖는 경향이 있고 거기에서 여러 자녀가 있습니다. 예:
4 개의 자식은 모두 루트에서 복제되고 루트에서 푸시 / 풀링됩니다. 그런 다음 루트는 네트워크 / 인터넷 어딘가에있는 마스터 리포지토리에서 푸시 / 풀링합니다. 루트는 일종의 개인 준비 영역 역할을합니다.
따라서 귀하의 경우에는 새 저장소를 복제하고 작업을 시작하면됩니다. '보관 된'작업은 다른 저장소에 그대로 둡니다. 그렇게 간단합니다.
유일한 단점은 디스크 공간 사용량입니다.하지만 그것이 우려된다면 DVCS를 전혀 사용하지 않을 것입니다.) 아, 그리고 그것은 Visual Studio "최근 프로젝트"목록을 오염시킵니다.
[다음 댓글 편집] :-
결론적으로 ... 당신이하는 일은 완전히 훌륭하고 정상적입니다. 다음 사항이 참일 때 작업하는 가장 좋은 방법이라고 생각합니다. 1) 수명이 짧습니다. 2) 다른 개발자와 협업 할 필요가 없습니다. 3) 변경 사항이 커밋 될 때까지 PC를 떠날 필요가 없습니다. / 푸시 시간.