2010-05-18 6 views
2

이 시나리오를 밖으로 던져서 가장 객관적이고 바닐라 머큐리얼 방식으로 수정하는 방법을 알고 싶습니다.Mercurial (또는 Git) 브랜치가 잠기는 것을 어떻게 막을 수 있습니까?

한다고 가정 내 중앙 집중식이 아닌 분산 된 웹 응용 프로그램 내 중앙 머큐리얼 저장소에서 다음 지점이 : 열

repository 
    default 
    feature1 
    feature2 
    bugs 

한다고 가정 개발자가 '버그'지점에 수정을 약속하고 추진해 왔습니다을. 이제 발표 할 시간이 왔다고합시다. 그래서 몇 가지 최종 테스트를하고 갑자기 버그 수정 문제가 있음을 알게되었습니다.이 문제는 수정하는 데 몇 시간이 걸릴 것입니다. 그래서, 이제는 공개해야만하는 매우 중요한 버그 수정이 있습니다. 그러나 '버그'분기는 잠겨 있으며, '고정'분기와 릴리스로 병합 할 수 없으며 반 고정 버그도 릴리스 될 것이므로, 나는 그런 일이 일어나도록 내버려 둘 수 없다.

그럼 어떻게해야합니까?

버그 분기의 변경 사항을 취소하고 버그를 기본값으로 병합하고 릴리스해야합니까? 이 특정 문제와 관련된 커밋이 10 개 (버그 수정) 인 경우 모두 찾아서 되돌 리니? 그 털이 들리는데, 내가 그렇게한다고 해 봅시다. 문제를 해결해야하는 개발자 - 버그 수정이 자신의 저장소를 가져오고 업데이트하는 경우는 어떻습니까? 그의 변화는 모두 되돌아 갈 것입니다. 그는 되돌리기를 되돌릴 수 없습니다 ... 갈 길은 무엇입니까?

또 다른 옵션은 cherry-picking을하고 'bugs'브랜치에서 문제 - 버그 수정 커밋을 제외하고 싶은 변경 사항을 'default'브랜치에 병합하는 것입니다. 그러나 이것은 이전에 제안 된 솔루션보다 더 털이 들립니다.

모두 어떻게합니까?

답변

1

나는 (출시를 만들기 위해) 새로운 지점을 만들 것입니다 :

  • 을 시작, 현재 문제가

버그 수정의 되돌리기로 지점 버그

  • 를 "고정" 그리고 나는 "버그"브랜치를 그대로 두었습니다. 체리 따기는하지 않습니다.

  • +0

    새 분기를 만들고 문제가있는 버그 수정을 되 돌린 후에는 새 분기를 기본값으로 병합하고 기본값에서 해제 할 것을 제안합니까? 아니면 우리가 그 새로운 지부에서 바로 석방을 제안 하시겠습니까? –

    +1

    @Chad : 새 지점에서 직접 해제 할 수 있습니다. 릴리스 관리의 트릭은 다음과 같습니다. "릴리스가 생성 된 지점은 중요하지 않습니다. ** 태그 **가 있습니다." 릴리스에 문제가있는 경우 올바른 태그에서 올바른 소스를 참조 할 수 있어야합니다. 이 태그가 지점 b1 또는 b2 또는 b-blah에 설정되었다는 사실은 그와 관련이 없습니다. – VonC

    +0

    흠, 잘 알고 있습니다. 고마워요 폰. –

    관련 문제