Mercurial Working 팀에서

우리는 Mercurial에 초보자이며, 우리는 평가 등을 통해 얻었고, 지금 그것을 실제 사용하고 있습니다.Mercurial Working 팀에서

문제는 우리 팀에서 사용하는 방식입니다.

우리는 몇 가지 조사를했으며이 링크는 같은 문제처럼 보였지만 해결책은 약간 복잡하여 실제로 사용하기에 적합합니다. http://blogs.oracle.com/tor/entry/mercurial_tip_checking_in_regularly.

우리의 문제는 같은 소프트웨어 프로젝트에서 일하는 사람들로 구성된 팀이 있습니다. 우리는 게이트 키퍼 모델을 사용하여 푸시를 단계적으로 수행합니다.

한 팀원이 "파일 A"에 큰 변화를 일으키고 있습니다. 잠시 시간을 할애하여 변경 작업을 로컬에서 수행하고 있습니다.

파일 A에서 작업하는 중에 문제를 해결하고 파일 B에서 문제를 해결하라는 메시지가 나타납니다. 이는 다른 개발자를 돕기위한 것입니다. 어떻게 할 수 있니? 그는 파일 A가 게이트 키퍼로 들어가는 불완전한 변경을 원하지 않지만 파일 B의 변경 사항을 밀어 넣어야합니다.

출처

2011-07-01 user563251

가지가 __really__ 저렴하다는 것을 명심하십시오. 당신이 얻은 하나의 대답은 개발자가 공유 게이트 키퍼 저장소에서 자신의 컴퓨터에있는 다른 지점을 복제하게하십시오. – Omnifarious

개발자가 File_B_Fix 또는 유사한 로컬 디렉토리를 새로 만든 다음 공유 저장소를 복제하도록하십시오. 파일 B에 대한 수정 사항을 작성한 후 변경 사항을 다시 공유 저장소로 푸시하십시오.

출처

2011-07-01 21:22:32

저는 지사를 사용하고 싶습니다. 현재 각 새 기능에 대해 명명 된 분기를 만듭니다. 그런 다음 버그 수정이 필요한 경우 update 명령을 사용하여 안정 또는 기본값 (원하는대로)으로 이동할 수 있습니다. 클론을 사용할 수도 있습니다. 차이점에 대한 의견을 보려면 Mercurial: Named Branches vs Multiple Repositories 및 A Guide to Branching in Mercurial을 참조하십시오.

출처

2011-07-06 12:06:22 masebase

이 특정 사례에 대해서는 일반적으로 제공되는 유연성을 추가하기 위해 Mercurial Queues을 배우고 사용하는 것이 좋습니다. Mercurial을 사용하는 모든 사람들이 워크 플로우에 추가해야 할 중요한 도구입니다. 귀하의 경우에는

는 팀 구성원 할 것 :

hg qinit -c 
hg qnew changes-to-fileA # creates a new patch with the outstanding changes 
hg qnew changes-to-fileB # creates a new empty patch 

# work on file B 

hg qrefresh    # updates the patch with changes to file B

는 REPO 이러한 변경 사항을 적용하는 방법에 대한 MQ tutorial을 읽어보십시오.

확장명이 shelve 인 경우 임시 변경 사항을 제외하고 파일 B에서 작업 한 다음 변경 사항을 복원 할 수 있습니다. 그러나 MQ를 사용하면 많은 추가 이점이 있습니다.

출처

2011-09-25 17:23:02 imiric

Mercurial Working 팀에서

답변

관련 문제