Mercurial — 이전 버전으로 돌아가서 계속 진행


249

프로젝트에 Mercurial을 로컬로 사용하고 있습니다 (다른 곳으로 밀거나 당기지 않는 유일한 레포지토리입니다).

현재까지는 선형 이력이 있습니다. 그러나 현재 내가 지금하고있는 일은 끔찍한 접근법이며 시작하기 전에 버전으로 돌아가 다른 방법으로 구현하고 싶습니다.

Mercurial 의 branch/ revert/ update -C명령 과 약간 혼동됩니다 . 기본적으로 나는 버전 38 (현재 45)로 되돌리고 다음 커밋이 38을 부모로 가지고 거기에서 계속 수행하고 싶습니다. 39-45 개정판이 영원히 손실되거나 자체적 인 데드 엔드 브랜치로 끝나더라도 상관 없습니다.

어떤 명령 / 명령 세트가 필요합니까?


6
관심이 있으신 분은 관련 사이드 바에 팝업으로 표시되어 되돌리기 대 업데이트에 대한 훌륭한 설명입니다. stackoverflow.com/questions/2506803/…
Paolo

답변:


150
hg update [-r REV]

나중에 커밋하면 효과적으로 새 분기를 만듭니다. 그런 다음이 분기에서만 계속 작업하거나 기존 분기를 병합 할 수 있습니다.


6
다음 커밋은 새로운 브랜치를 만듭니다. 확실하지 않은 경우 (복사본을 사용하여) 저장소를 백업하고 시도하십시오. 결과를 좋아하지 않습니다.-> 무료로 처음부터 시작하십시오.
van

이것은 현재 변경 사항을 이전 개정판과 병합하여 원하지 않는 것일 수 있으므로 모호한 답변입니다. 정답은 hg 되돌리기 여야합니다.
Trevor de Koekkoek

병합에 관한 내용을 제외하고는 대답이 좋습니다 (질문자가 병합하기를 원하지는 않습니다).
ctrl-alt-delor

3
@NeonWarge REV는 단순히 개정의 자리 표시 자입니다. 숫자, 해시, 책갈피 등이 될 수 있습니다. 트레버 (Trvor) : 이것은 아무것도 병합하지 않기 때문에 모호하지 않습니다. 필요가 없습니다.
DanMan

401

명령에 대한 치트 시트는 다음과 같습니다.

  • hg update작업 사본 상위 개정을 변경하고이 새 상위 개정과 일치하도록 파일 컨텐츠도 변경합니다. 즉, 새 커밋은 업데이트 한 개정에서 계속 수행됩니다.

  • hg revert파일 내용 만 변경하고 작업 사본 상위 개정판 만 남겨 둡니다. 일반적으로 hg revert작업 복사본에 파일에 대한 커밋되지 않은 변경 사항을 유지하지 않으려는 경우 사용 합니다.

  • hg branch새로운 지사를 시작합니다. 명명 된 분기를 변경 세트에 할당 한 레이블로 생각하십시오. 따라서 그렇게하면 hg branch red다음 변경 세트가 "빨간색"분기에 속하는 것으로 표시됩니다. 이는 특히 다른 사람들이 서로 다른 브랜치에서 작업하고 나중에 변경 세트가 시작된 곳을보고 싶을 때 변경 세트를 구성하는 좋은 방법입니다. 그러나 상황에 따라 사용하고 싶지 않습니다.

을 사용 hg update --rev 38하면 변경 세트 39–45는 막 다른 골목 (우리가 부르는 매달려있는 머리)으로 남게됩니다. 푸시 할 저장소에 "다중 헤드"를 작성하므로 푸시 할 때 경고가 표시됩니다. 경고는 누군가가 합병을해야한다고 제안하기 때문에 그런 머리를 두는 것은 무례한 행동이기 때문입니다. 그러나 귀하의 경우에는 계속 진행할 수 있으며 hg push --force실제로는 그대로두고 싶습니다.

아직 39-45 개정판을 다른 곳에 푸시하지 않았다면 비공개로 유지할 수 있습니다. 매우 간단합니다. hg clone --rev 38 foo foo-38최대 개정 38 만 포함하는 새로운 로컬 복제본을 얻게됩니다. 계속해서 작업 foo-38하면서 새로 생성 한 변경 세트를 푸시 할 수 있습니다. foo복제본 에는 여전히 오래된 (나쁜) 개정판이 있습니다 . (당신이 원하는 그러나 당신은, 예를 들어, 클론의 이름을 바꿀 무료 foofoo-badfoo-38foo.)

마지막으로 사용 hg revert --all --rev 38하고 커밋 할 수도 있습니다 . 그러면 개정판 38과 동일한 개정판 46이 작성됩니다. 그런 다음 개정판 46에서 계속 작업합니다. 이렇게해서 명시 적으로 동일한 방식으로 기록에 포크를 작성 hg update하지는 않지만, 다른 한편으로는 여러 머리. hg revert개정판 45를 기반으로 이미 자체 작업을 수행 한 다른 사람들과 공동 작업 하는 경우 사용 합니다 hg update. 그렇지 않으면 더 명확합니다.


2
멋진 답변입니다. 나는 hg revert --all --rev ##을 사용했고 내 엉덩이를 구했다 : D
Van Thoai Nguyen

1
매달려있는 머리의 가지 도 닫는 것이 낫지 않습니까? 그러면 저장소에 대한 향후 경고가 발생하지 않습니다. 참조 stackoverflow.com/a/3688320/900130
졸탄

참고 : hg revert --all --rev xxx는 로컬 리포지토리에서 복귀하는 데 필요한 로컬 파일을 수정합니다. 따라서 되돌리려는 위치로 업데이트하기 전에 업데이트해야합니다.
Vincent

이전 버전을 분기하려면 먼저 되돌리기를 한 다음 업데이트해야했습니다. 그것은 대부분의 것보다 덜 불투명 한 설명입니다.
CodeLurker

30

커밋과 푸시를 한 직후에 하나의 파일을 이전 버전으로 되돌려 야하는 경우가 발생했습니다. 이러한 개정판을 지정하는 간단한 구문은 다른 답변에서 다루지 않으므로 여기에 해당 명령이 있습니다.

hg revert path/to/file -r-2

-2사용하여 마지막으로 커밋하기 전에 버전으로 되돌아갑니다 -1단지 현재 커밋되지 않은 변경을 되돌릴 것입니다.


1
나는 이것이 매우 유용하다고 생각합니다. 물론 -r 옵션의 경우 개정 번호를 제공 할 수 있습니다.
Alex

특정 개정을 선택할 수도 있습니다. 예 :hg revert path/to/file -r478
Matt

7

IMHO는 hg strip -r 39이 경우에 더 적합합니다.

mq 확장자가 활성화되어 있어야하며 Martin Geisler가 권장하는 "복제 저장소 방법"과 동일한 제한 사항이 있습니다. 변경 세트가 어떻게 든 게시 된 경우 변경 사항만으로 인해 특정 시점에 저장소로 돌아갑니다 (아마도) 지역 리포지토리.


이것에 대해 몰랐습니다. 저장소를 삭제하고 다시 복제하는 것보다 쉽고 깔끔합니다. 감사.
분석 재개 모니카 - notmaynard

6

사용 후에 hg update -r REV는 변경 사항을 커밋하여 푸시 할 수있는 방법에 대한 대답이 명확하지 않았습니다.

업데이트 후 커밋을 시도하면 Mercurial은 변경 사항이 없다고 생각합니다.

Mercurial은 파일을 변경해야하므로 (README와 같이) Mercurial은 새로운 변경 사항을 인식하고이를 커밋 할 수있었습니다.

그런 다음 언급 한대로 두 개의 머리를 만들었습니다.

푸시하기 전에 다른 헤드를 제거하기 위해 No-Op Merges 단계를 따라 해당 상황을 해결했습니다.

그때 나는 밀 수 있었다.


당신은 commit --close-branch오래된 지점에서 할 수 있습니다 . push -f새 헤드를 밀 수도 있지만 현재 헤드와 혼동 될 수 있습니다.
ctrl-alt-delor

5

위의 답변이 가장 유용했으며 많은 것을 배웠습니다. 그러나 내 요구에 대한 간결한 대답은 다음과 같습니다.

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

여기서 ${1}개정 번호 또는 지점 이름입니다. 이 두 줄은 실제로 bash 스크립트의 일부이지만 수동으로 수행하려는 경우 자체적으로 잘 작동합니다.

이것은 릴리스 브랜치에 핫픽스를 추가해야하지만 기본값에서 빌드해야하는 경우에 유용합니다 (CI 도구를 올바르게 가져와 브랜치에서 빌드 한 후 릴리스 브랜치로 제거 할 때까지).


1

Tortoise Hg (Mercurial 용 무료 GUI)를 설치하고 사용합니다. 그런 다음 되돌릴 수있는 개정판을 마우스 오른쪽 버튼으로 클릭하면 눈앞에 모든 커밋 메시지와 함께 '모든 파일 되돌리기'가 있습니다. 파일 세트 버전간에 직관적으로 쉽게 롤백 할 수 있으며 문제가 처음 발생한 시점을 설정하려는 경우 매우 유용합니다.

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