나는 수은의 분기에 혼란스런 자식 사용자입니다. 작은 변화를 어떻게 추적해야합니까?


32

나는 항상 이전에 git을 사용했지만 파이썬에 기여하고 싶기 때문에 수은을 배워야하며 매우 실망 스럽습니다.

그래서 몇 가지 작은 패치를 만들었고 로컬 수은 저장소에서 커밋으로 추적하고 싶었습니다. 분명히 수은에서 분기를 처리하는 4 가지 방법이 있습니다 . 1과 4는 나에게 완전히 어리석은 것처럼 보였습니다. 지명 된 지점은 헤비급 것처럼 보였고 빠른 1 커밋 수정에 사용하지 않아야한다고 생각합니다. 그래서 책갈피를 사용했습니다.

이제 패치가 거부되고 내 저장소에서 책갈피 지점 중 하나를 제거하려고합니다. 좋아, 자식에서는 분기를 강제 삭제하고 잊어 버릴 것이므로 북마크를 삭제하면 다음과 같은 문제가 발생합니다.

  • TortoiseHG는 hg log여전히 커밋과 default브랜치에 2 개의 헤드가 있음을 보여줍니다 . 그리고 내가 올바르게 이해하면 추가 플러그인없이 hg에서 커밋을 삭제할 수 없습니다.

  • Mercurial에는 해시뿐만 아니라 개정 번호도 있습니다. 내 커밋을 두 개 추가함에 따라 모든 커밋은 메인 중앙 저장소와 수정 번호가 다릅니다.

  • 내가 할 hg update내 이동 당겨 후 master최신 자동 커밋에 북마크를,하지만 난 TortoiseHG에서 그렇게 할 수있는 방법을 찾을 수 없습니다.

내가 무엇을 잘못하고 있지? 이것은 정상이며 예상되는 것이므로 이러한 문제를 무시해야합니까? 아니면 내 지점과 어떻게 일해야합니까?

답변:


22

개인적으로, 귀하의 시나리오의 경우, 핵심 개발자가 각 변경 사항을 승인 해야하는 여러 변경 작업을 수행하지 않는 한 지점을 만들지 않아도됩니다.

리포지토리를 복제하고 작업 한 다음 풀 요청을하십시오.

분기를 사용하려면 오히려 명명 된 분기를 사용하고 싶습니다. 그들은 북마크가 없었던 정확한 목적을 위해 설계되었습니다. 왜 당신이 그것을 헤비급이라고 생각하는지 모르겠습니다.

머큐리얼은 위키에 전체 " 죽은 가지 가지 치기 "방법을 설명하는 페이지를 가지고 있습니다 . "클론 사용"옵션이 요구 사항을 충족해야합니다.

보다 구체적인 문제에 답변하려면 ...

TortoiseHG 및 hg 로그에는 여전히 커밋 및 기본 분기에 2 개의 헤드가 있음이 표시됩니다. 그리고 내가 올바르게 이해하면 추가 플러그인없이 hg에서 커밋을 삭제할 수 없습니다.

내가 처음에 Mercurial에서 저지른 실수입니다. 추가 플러그인을 두려워하지 마십시오. 그중 일부는 매우 강력한 도구이며 종종 핵심 제품으로 가져옵니다. 머큐리얼의 작동 방식 특정 작업을 수행하는 데 필요한 작업이 있으면 사용하십시오.

역사를 수정하는 것은 Mercurial 세계에서 나쁜 것으로 간주되므로 바닐라 제품에는 Git 사용자가 생각하는 모든 것이 항상 포함되어 있지는 않지만 응용 프로그램을 사용하고 싶지만 우선 순위가 다른 사람들을위한 플러그인이 많이 있습니다.

Mercurial에는 해시뿐만 아니라 개정 번호도 있습니다. 내 커밋을 두 개 추가함에 따라 모든 커밋은 메인 중앙 저장소와 수정 번호가 다릅니다.

개정 번호에 대해 걱정하지 마십시오. 그것들은 더 이상 편의의 문제입니다. 해시 코드는 리포지토리에서 리포지토리로 전달되는 중요한 식별자입니다. 리포지토리간에 개정 번호가 일치하지 않습니다. 좋은 설명은 Hg Init 를 확인하십시오 .

개정 번호는 단일 리포지토리로 작업 할 때 편리하고 기억하기 쉬운 바로 가기입니다.

마스터 북마크를 최신 커밋으로 자동으로 이동 한 후 hg 업데이트를 수행하지만 TortoiseHG에서 해당 방법을 찾을 수 없습니다.

TortoiseHG를 사용할 때는 다른 도구 대신 워크 벤치를 사용하십시오 . 모든 것이 (거의) 거기에 있습니다. 업데이트는 개정 컨텍스트 메뉴에 있습니다. 그것은 아니다 항상 직관적하지만, 위의 링크에서 좋은 가이드가 당신이 그것에 익숙해, 당신은 자신이 포기 멀리 클릭하면 끝.


적절한 이름의 브랜치가 hg
jk

9

분명히 수은에서 분기를 처리하는 4 가지 방법이 있습니다. 1과 4는 나에게 완전히 어리석은 것처럼 보였습니다.

Mercurial에서는 지점을 만들지 않습니다 . 모든 커밋은 사실상 브랜치이며 모든 커밋은 여러 부모와 자식을 가질 수 있습니다. 이것이 동일한 엔티티를 구성하는 네 가지 방법입니다.

당신 그들에게 다른 이름을 줄 수 있습니다 , 당신 필요는 없지만, 좋은 생각입니다. 명명 된 브랜치에 대한 헤비급은 없습니다. 추가 메타 데이터 일뿐입니다. 나는 개인적으로 어떤 상황에서든 지명 된 지점을 다른 무엇보다 선호합니다.

TortoiseHG 및 hg 로그에는 여전히 커밋 및 기본 분기에 2 개의 헤드가 있음이 표시됩니다.

바로 모든 것을에 덤프하지 않고 명명 된 분기를 사용하는 이유 default입니다.

그리고 내가 올바르게 이해하면 추가 플러그인없이 hg에서 커밋을 삭제할 수 없습니다.

실제로 Mercurial에서 아무것도 삭제할 수 없으며 해서는 안됩니다 . 사용할 수는 hg strip있지만 기록되지는 않습니다. 기본적으로 로컬 리포지토리의 일부만 잘라냅니다. 당신은 그것을 밀 수 없으며, 당신이 지역을 벗긴 지점이있는 저장소에서 당기면 다시 나타납니다.

Mercurial에는 해시뿐만 아니라 개정 번호도 있습니다. 내 커밋을 두 개 추가함에 따라 모든 커밋은 메인 중앙 저장소와 수정 번호가 다릅니다.

숫자는 아무 의미가 없습니다. 그들이 당신을 혼동하면 무시할 수 있습니다.

마스터 북마크를 최신 커밋으로 자동으로 이동 한 후 hg 업데이트를 수행하지만 TortoiseHG에서 해당 방법을 찾을 수 없습니다.

TortoiseHG를 사용 hg pull -u하지 않았지만 pull및을 모두 수행합니다 update.

나는 항상 이전에 git을 사용했지만 파이썬에 기여하고 싶기 때문에 수은을 배워야하며 매우 실망 스럽습니다.

많은 Mercurial 사용자는 Git (나 포함)에 대해 동일하게 생각합니다.


6

Mercurial과 Git이 비슷한 경우에도 서로 다른 디자인을 가지고 있습니다. 아마도 가장 중요한 디자인 차이는 Mercurial에서 히스토리를 수정하는 것이 git처럼 유연하지 않다는 것입니다.

짧은 대답 : 적은 양의 변경 사항이 있더라도 상관없이 분기를 사용할 수 있습니다. 해당 브랜치를 삭제하려는 경우 나중에 책갈피 를 삭제하고 나중에 변경 사항을 제거 할 수 있도록 책갈피 를 사용하십시오 .

먼저, 당신이 언급 한 것들 중 일부를 조금 밝히려고 노력하십시오.

  • 1과 4는 브랜칭으로 간주됩니다. 커밋 할 때마다 기술적으로 브랜치 인 명명되지 않은 브랜치를 효과적으로 생성하기 때문입니다 (소스 / 축복 저장소에 같은 시간에 다른 커밋이있는 경우). 방법 4에서는 새 "헤드"를 만드는 반면 방법 1에서는 그렇지 않습니다 . 헤드는 병합되어야합니다. 나는 방법 1이 어리석은 것에 동의하지만 일부는 그것을 좋아하는 것 같습니다 ... 작은 프로젝트의 경우에는 추측합니다.

  • 방법 2에 관해서 는 가지가 무겁지 않고 영구적 입니다. 스트립 확장과 같은 것을 사용하지 않으면 분기를 제거 할 수 없습니다. 다시 말하지만 Mercurial의 디자인 철학은 역사를 수정하는 데에 그치지 않습니다 (그러나 더 나아졌습니다).

  • 에 관한 개정 번호 , 그들은 단지 지역보다 인간적으로 읽을 참조입니다 당신이 개정해야 할 모든 명령을 사용합니다. 해시 사용을 좋아한다면 여전히 할 수 있습니다. 개정 번호는 지름길이며 다른 저장소 간의 내부 작업에 대해서는 Mercurial에서 무시합니다.

이제 다른 질문에 대답하십시오.

  • 당신이 가진 헤드를 확인할 수 있습니다 hg heads. 하나의 명명 된 브랜치에 2 개 이상의 헤드가 있으면 병합되는 것이 좋습니다. 아마 당신의 북마크가있는 곳일 것입니다 .
  • 방금 수정 한 내용을 제거하려면 할 수는 hg rollback있지만 그렇지 않은 것 같습니다.
  • 북마크를 삭제하려면 hg bookmark --delete yourbookmark
  • 역사에서 가지를 자르기가 쉽다는 것이 기쁠 것입니다. Rebase 확장Strip 작업을 살펴보십시오 .
  • Mercurial에는 이미 여러 개의 확장이 번들로 제공되지만 기본적으로 활성화되어 있지 않습니다 . 임의의 폴더로 이동하고 아무 곳이나 마우스 오른쪽 버튼으로 클릭하여 TortoiseHG 상황에 맞는 메뉴를 열고 전역 설정으로 이동 한 다음 확장으로 이동하십시오. MQ 확장 및 Rebase 확장을 활성화하십시오. 이것은 리포지토리 간 호환성을 손상시키지 않습니다.
  • 이제 당신은 여기에 있습니다 :
    • 북마크가 시작된 위치 제거 (문제가 해결되었을 수 있음)
    • 더 쉽게 시각화하기 위해 변경 사항을 전면에 리베이스 한 다음 나중에 제거 할 수 있습니다. 나는 다른 시간에 당신에게 도움이 될 수 있기 때문에 rebase를 언급했습니다.

또한 git 에서는 명시 적으로 푸시해야하고 나중에 삭제할 수 있기 때문에 "private local branch" 를 가질 수 있습니다. 의욕에 당신은 당신이 가지고있는 모든 밀어 그러나, 이 피하고 싶은 경우에 당신이 사용할 수있는 페이즈 기능비밀로 개정 세트를 표시합니다 . 비밀 개정판은 푸시되지 않습니다.

마지막으로, 당신은 잘못된 일을하지 않고 단지 약간 다른 사고 방식으로 만들어진 다른 도구라는 것을 명심하십시오. 히스토리 수정 (git) 또는 히스토리 수정 (hg)으로 거의 요약됩니다. Mercurial에서는 역사 (특히 Phases)를 수정하여 발에 쏠 기가 더 어렵 기 때문에 git보다 더 나은 이유가 있습니다.


명명 된 분기를 기록하는 변경 세트의 모든 분산 사본이 실행 된 후에 삭제되도록 보장 할 방법이 없습니다 hg strip. 명명 된 브랜치에 전역 네임 스페이스가 있고 Git 브랜치 이름이 없다는 점을 제외하고는 Git 브랜치 이름의 분산 사본에 대해 동일한 주장을 할 수 있다고 생각합니다. 그리고 이름 분기로 인해 여러 헤드가 존재합니다. 분산 형 VCS의 감염성 디자인 오류입니다.
쉘비 무어 III

1

나는 수은으로 가지에 대해 걱정하지 않는 것이 가장 쉽다는 것을 알았습니다. 나는 역사에서 어디에서 편집하고 커밋을 생성 할 것인지 (익명 브랜치)를 찾습니다. 때로는 다른 상황에서 머리 사이를 뛰어 넘어야하지만 책갈피를 신경 쓰지 않는 경우 책갈피가 유용 할 수 있습니다. 명명 된 브랜치는 오래 지속되는 브랜치 (버그 수정 브랜치, 프로젝트 브랜치)에는 문제가 없지만 1 또는 2 커밋 수정의 경우 작업에 적합한 도구가 아닙니다.

익명 브랜치의 트릭은 푸시하지 않으려는 경우 즉, 로컬로 유지하려는 경우 해당 단계를 "비밀"로 설정하는 것입니다. 당신이 경우 않는 그들을 밀어 싶지만, 당신이 그들에 따라 더 이상 커밋하지 않으려는, 당신은 단지 그들이 더 이상 '머리'목록과 수은에 표시 의미하는 그들의 상단에 "--close-분기를"커밋 해당 지점의 여러 헤드에 대한 불평을 중단합니다.


-1

브랜치 대신 북마크를 사용할 수 있다고 생각합니다. 우리는 어쨌든 제품을 계속 지원할 것이며 두 지점을 장기적으로 병합하는 것은 큰 두통이 될 것입니다.

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