2011-01-13 4 views
6

Mercurial과 관련된 워크 플로우 질문이 있습니다 (다른 DVCS에 적용 가능할 수도 있음).버전 관리 : 기능 개발 관련 버그 수정/코드 이동

repo는 일반적인 기본/안정 설정을 사용하여 설정됩니다.

새로운 기능을 빌드하고 시간이 좀 걸릴 것으로 기대됩니다 (월 +). 이 기능을 사용하는 중에 나중에 수정해야하는 버그를 발견하게됩니다. 또는 더 잘 문서화 될 수있는 코드를 발견했을 것입니다.

내 가정은 기본적으로 수정 프로그램을 만든 다음 안정 프로그램으로 전환하고 수정 프로그램을 다시 작성하는 것입니다 (직접 또는 패치 적용). 그게 맞습니까? 아니면 즉시 안정으로 전환해야합니까? 거기서 변경 한 다음 안정을 기본값으로 병합 하시겠습니까?

패치를 사용하면 더 나을 것 같습니다. 버그 수정을 위해 특별히 커밋을하고 편리하게 패치를 적용 할 수 있습니다. 버그가 너무 심해서는 안되며, 긴급함이 필요없고 흐름을 깨뜨릴 필요가 없습니다. 권리?

그래서이 상황을 어떻게 처리합니까?

덕분에 당신이 당신의 작은 수정을했으면

+0

참고 : Wim은 사용자가 고려할 수있는 체리 피킹에 대한 실행 가능한 대안을 제안합니다. – VonC

답변

6

당신은, 분기점 (개정 B)로 돌아 가기 (개정 X) 버그를 수정 한 다음 두 가지로 수정 (M1M2) 병합 할 수 있습니다 :

-----B--o----o---M1----o---> stable 
    |  /
    |---------X bugfix 
    |   \ 
    \--o---o----M2----o-----> feature 

당신이 할 수있는이 방법을 정상적인 hg merge 작업으로 각 지점에서 해결하십시오. 패칭, 이식 또는 MQ'ing이 필요하지 않습니다.

첫 번째 단계에서 버그를 소개 한 수정 버전으로 다시 돌아갈 수 있습니다. 이를 수정본의 기반으로 사용하면 버그가 포함 된 모든 분기에 수정 사항을 병합 할 수 있습니다.

+2

Huzzah, "어디에서"당신이 변화를하는지 이해하는 사람은 변화 자체만큼이나 중요합니다. –

+0

+1 기록 다시 쓰기를 방지합니다. – VonC

+0

왜 역사가 중복 되길 원하지 않는지 이해할 수 있지만 간단한 수정으로 "이식"이 가장 쉬운 방법 인 것처럼 보입니다. 병합이 일정 시간을 복잡하게 만들 수있는 타임 라인을 선명하고 직선적으로 유지하는 것으로 보입니다. 나는 게으르다 고 생각하니? – jbarreiros

0

당신이 Hg Transplant Extension를 사용하고 다른 지점에 같은 수정 사항을보고 할 수 있습니다, 커밋합니다.

다른 체리 피킹 가능성은 SO 질문 "Mercurial cherry picking changes for commit"에 자세히 설명되어 있습니다.

+0

VonC에 감사드립니다. 이식 장기 연장은 훌륭하게 진행될 것입니다. 링크 주셔서 감사합니다. – jbarreiros

+1

더 나은 워크 플로우로이를 피할 수 있습니다. 아래의 Wim의 솔루션은 다른 해시 ids를 사용하여 repo에서 동일한 변경으로 두 번 끝나지 않기 때문에 바람직합니다. 두 곳에서 동일한 변경을하면 결국 자동으로 그 장소가 병합됩니다. –

+0

@ Ry4an : 동의합니다. 그러나 또 다시, 나는 힘내 사용자와 너무 많이 추론한다;) – VonC