로컬 및 원격 Mercurial 저장소가 있다고 가정 해 보겠습니다. 이제 기능 작업을 시작합니다. 나는 그것을 작업하고 그것이 끝났다고 생각하면 변경 세트를 커밋합니다. 좀 더 테스트 해보면 코드에서 무언가를 수정하여이 기능을 더욱 향상시킬 수 있다는 것을 알았습니다. 나는 변화를 만들고 헌신한다. 20 분 후이 새로운 기능에 버그가 있음을 알게되었으므로 수정하고 커밋합니다.
예를 들어 "Implementing feature X"라는 메시지와 함께 하나의 변경 집합으로 원격 저장소에 실제로 푸시하려는 3 개의 변경 집합이 있습니다.
번거 로움없이 어떻게 할 수 있습니까? 나는 패치로 할 수 있다고 믿지만 많은 작업처럼 보입니다.
답변:
방법에 대한 축소 확장 ?
hg rebase --collapse. rebase 명령에 대한 hg wiki를 확인하십시오. 이 질문은 세 번째 전체 검색 결과이고 stackoverflow의 첫 번째 질문이기 때문에 정보가 유용 할 것이라고 생각했습니다.
hg rebasewith 를 사용할 수 있습니다 --collapse.
histedit의 확장은 당신이 찾고있는 정확하게이다.
hg histedit -o
또는
hg histedit --outgoing
나가는 변경 집합 목록이 나타납니다. 목록에서 다음을 수행 할 수 있습니다.
histedit는 "\ n *** \ n"을 구분하는 두 개의 메시지로 기본 설정되는 접힌 변경 세트의 새 커밋 메시지를 묻는 메시지를 표시합니다.
mq 확장을 사용하여 유사한 결과를 얻을 수도 있지만 훨씬 더 어렵습니다.
접기 확장을 사용하여 접기 만 할 수도 있지만 좋은 UI를 제공하지 않으며 결과 커밋 메시지를 편집하는 방법을 제공하지 않습니다. 결과 커밋 메시지를 편집하면 최종 메시지를 정리할 수 있으며, 이는 항상 사용하게됩니다.
예, 패치로 할 수 있습니다. 작업이 100에서 110까지의 변경 집합에 있다고 가정 해 보겠습니다.
패치 생성 :
% hg export -o mypatch 100:110 --git
99로 업데이트 :
% hg update 99
--no-commit을 사용하여 패치를 적용합니다 (그렇지 않으면 모든 변경 세트를 다시 가져옵니다).
% hg import --no-commit mypatch
모든 변경 사항을 한 번에 커밋합니다.
% hg commit
이제 두 개의 헤드 (110 및 111)가 있으며 이는 작업 디렉토리에서 생성하는 파일의 측면에서 동일해야합니다.
% hg strip 100
좋아, 이제 모든 철자를 다 써서 길어 보이지만 직접 여러 번 해본 결과 너무 많은 집안일이 아닙니다 ...
hg strip --keep한 번의 커밋으로 모든 것을 커밋하지 않습니까?
hg strip는 .hg/strip-backup/디렉토리에 백업을 배치합니다 . 나는 그것이 안전 git reflog하지는 않지만 여전히 일종의 구조를 제공 한다고 생각합니다 .
TortoiseHg를 사용하는 경우 두 개의 개정판을 선택하고 (다음이 아닌 개정판을 선택하려면 CTRL 사용) 마우스 오른쪽 버튼을 클릭 한 다음 "기록 압축"을 선택하십시오 .
그 후에는 이전에 선택한 첫 번째 변경부터 시작하여 새 헤드에 새 변경 목록이 표시되며 선택한 항목 사이의 모든 하위 변경 목록이 포함됩니다.
더 이상 필요하지 않은 경우 이전 변경 목록을 제거 할 수 있습니다 . MQ 확장을 사용하십시오. 다시 TortoiseHg에서 : 모든 하위 항목으로 제거해야하는 첫 번째 변경 목록 "Modify History-> Strip"을 마우스 오른쪽 버튼으로 클릭합니다 .
이 폴딩에 mq를 사용하는 선호하는 방법은 여기에 설명 된대로 TortoiseHg 를 사용하는 것 입니다. 그러나 다음과 같이 명령 줄에서 쉽게 수행 할 수 있습니다.
hg qimport -r <first>:<last>
-- where <first> and <last> are the first and last changesets
-- in the range of revisions you want to collapse
hg qpop <first>.diff
-- remove all except for the first patch from the queue
-- note: mq names patches <#>.diff when it imports them, so we're using that here
hg qfold <next>.diff
-- where <next> is <first>+1, then <first>+2, until you've reached <last>
hg qfinish -a
-- apply the folded changeset back into the repository
(qfold 단계를 수행하는 더 좋은 방법이있을 수 있지만 일반적으로 해당 작업에 TortoiseHg를 사용하므로 잘 모르겠습니다.)
처음에는 약간 복잡해 보이지만 일단 mq를 사용하기 시작하면 매우 간단하고 자연 스럽습니다. 또한 mq로 매우 편리 할 수있는 다른 모든 작업을 수행 할 수 있습니다!
hg collapse그리고 hg histedit가장 좋은 방법입니다. 아니면, 그들이 안정적으로 작동한다면 최선의 방법이 될 것입니다 ... histedit3 분 안에 스택 덤프와 충돌하게되었습니다. Collapse그다지 좋지 않습니다.
다른 두 BKM을 공유 할 수 있다고 생각했습니다.
hg rebase --collapse
이 확장은 Mercurial과 함께 배포됩니다. 아직 문제가 없었습니다. hg rebase제한 을 해결하기 위해 몇 가지 게임을해야 할 수 있습니다.
저장소 ( foo/.hg)를 작업 디렉토리 ( bar) 및 해당 파일로 이동합니다. 그 반대는 아닙니다.
어떤 사람들은 두 개의 클론 트리를 만들고 그 사이에 파일을 복사하는 것에 대해 이야기했습니다. 또는 그들 사이에 패치. 대신 .hg디렉토리 를 이동하기가 더 쉽습니다 .
hg clone project work
... lots of edits
... hg pull, merge, resolve
hg clone project, clean
mv work/.hg .hg.work
mv clean/.hg work/.hg
cd work
... if necessary, pull, nerge, reconcile - but that would only happen because of a race
hg push
이는 실제 저장소 인 .hg트리가 작업 디렉토리 및 해당 파일과 독립적 인 한 작동합니다.
그들이 독립적이지 않다면 ...
histedit이 작업에 매우 적합한 옵션입니다. 나는 여전히 git rebase -i를 할 때 그것을 신뢰하지 않지만 충돌하지 않습니다 .. 적어도 최신 버전은 무언가가 끔찍하게 잘못되면 임시 브랜치에 남겨 두어 변경 세트가 제거되는 유일한 시간입니다. 새 브랜치가 커밋 된 후입니다.
저는 Mercurial을 사용 해본 적이 없지만, 얼마 전에 Martin Fowler가 그의 블로그에서 이야기 한 것과 비슷하게 들립니다.
왜 hg strip --keep명령 하지 않습니까?
그런 다음 모든 변경 사항을 하나의 커밋으로 커밋 할 수 있습니다.
HistEdit는 당신이 원하는 것을 할 것이지만 아마 과잉 일 것입니다. 필요한 유일한 것이 일부 변경 세트를 함께 접는 것이라면 Collapse Extension 이 작업을 수행합니다.
당신이 게시되지 않은이 있다고 가정 THIS하고 THAT의욕에 커밋하고 단일로 가입 같은에서 커밋 THIS시점 ::
... --> THIS --> ... --> THAT --> ... --> LAST
커밋이 게시되지 않았는지 확인하십시오.
$ hg glog -r "draft() & ($THIS | $THAT)"
LAST커밋 업데이트 ::
$ hg up
커밋 THIS을 MQ로 가져옵니다.
$ hg qimport $THIS::.
모든 패치를 적용 취소하고 먼저 적용하십시오 THIS::
$ hg qpop -a
$ hg qpush
$ hg qapplied
... THIS ...
THAT::로 가입
$ hg qfold $THATNAME
참고 이름 THATNAME사용 을 찾으려면 :
$ hg qseries
모든 패치를 적용하고 저장소 기록으로 이동 ::
$ hg qpush -a
$ hg qfinish -a
주제에 대한 내 블로그 게시물 은 Mercurial에서 두 개의 커밋에 참여하고 있습니다.