DVCS가 왜 모두 확약되지 않은 변화에 대한 비이성적 인 공포증을 겪는 것처럼 보이는가?

SVCS 배경에서 비롯된 DVCS 시스템 작업에 익숙해지기 가장 어려운 것 중 하나는 시한 시한 폭탄과 같은 커밋되지 않은 변경 사항 을 모두 고려하는 방식 입니다.

Mercurial에서 변경 사항을 가져 오려고 시도하고 작업 사본에 커밋되지 않은 변경 사항이있는 경우 들어오는 변경 사항을 병합하기 위해 후프를 뛰어 넘어야합니다. 분기를 전환 하시겠습니까? 그것은 당신이 모든 것을 보류하도록 강요 할 것이고, 당신은 다른 쪽 끝에서 즉시 그것을 풀어야합니다. (SVN은 이러한 시나리오 중 하나에 문제가 없습니다.)

힘내 같은 방법입니다. 나는 프로젝트에서 다른 개발자와 나란히 일하고 있으며, 그의 커밋 중 하나를 내 포크로 선택하려고했습니다. 커밋에서 변경된 파일과 완전히 다른 파일에서 작업 복사본에 커밋되지 않은 변경 사항이 있기 때문에 허용하지 않았습니다 . 병합 옵션조차 없습니다. 분명히 내 변경 사항을 먼저 숨겨야합니다!

어떤 사람이 그러한 극도의주의를 기울여서 완전히 무해한 것을 치료해야한다면, 나는 그것을 정신 장애로 간주해야하는 비이성적 인 두려움 인 "공포증"이라고 부릅니다. 그러나 Git과 Mercurial은 지능적이고 합리적인 개발자로 구성된 두 팀으로 설계되었으므로 내가 모르는 것을 알고 있는지 궁금합니다.

커밋되지 않은 변경에 대한 이러한 태도를 정당화하는 기술적 이유가 있습니까? 그렇다면 왜 문제가 DVCS에만 존재하는 것입니까?

1. DVCS 세계에서는 커밋이 저렴하고 역사는 변경 가능합니다. WIP는 원하는대로 "더러운"상태 일 수 있습니다. "저장할 변경 세트에서 현재 상태를 삭제"에 대한 이유를 알 수 없습니다.
2. SVN 히스토리는 선형이므로 새 개정 본의 변경 사항과 초안을 병합 해야합니다 . 불러 온 외부 변경 사항을 사용하여 즉석에서 수정 된 작업 디렉토리에 병합하는 것보다 DVCS 사용 (자연적으로) DAG 및 분기 된 히스토리에 대한 추가 헤드 (커밋 + 풀 + 업)가 더 안전합니다.
3. Subversion에서 수정 된 WC 를 ( 일부 노드로 ) 전환하면 잠재적 으로 하나의 추가 병합 이 제거 됩니다 ( "오래된 커밋"- "스위치"- "1 수정 범위 병합"과 반대로). SVN은 완벽한 도구가 아니며 DVCS에는 전혀 문제가되지 않습니다.

이력서

그것은 공포증이 아니며, 좋은 태도를 지키기 위해 " 가혹한 " 시행 입니다.

마지막 hg qnew|qpop|qpush으로 깔끔하고 질서 정연한 가격입니다

를 병합하거나 체리 픽 git인하면 커밋이 즉시 생성됩니다. 커밋이 완료되고 기록의 일부가 될 때까지 작업이 완료되지 않습니다.

이제 git작업 디렉토리에서 커밋되지 않은 변경 사항을 처리 할 수 ​​있다면 어떻게 될까요? 병합 / 체리 픽을 처리해야하는 변경 / 병합 충돌과 자신이 도입 한 변경을 구별하는 데 다소 어려움이 있습니다. 또한 실제로 커밋 한 내용을 테스트하는 것은 거의 불가능합니다.

따라서 병합 상황에 대해 작업 디렉토리를 정리하면 작업을 단순하고 관리하기 쉽게 유지할 수 있습니다. 결국, 병합하기 전에 커밋되지 않은 변경 사항을 숨기고 나중에 변경하지 않아야합니다. 워크 플로우에서

git stash
git pull
git stash pop

두 개의 (!) 병합 작업이 있습니다. 하나는 마지막 커밋을 들어오는 변경 사항과 병합하고 다른 하나는 커밋되지 않은 변경 사항을 결과 병합 커밋과 병합합니다. 이런 식으로,이 세 가지를 무시하면서 단일 작업에서 세 가지를 하나로 통합하려고 할 때 발생하는 혼동을 피하면서 두 가지만 하나로 병합하면됩니다. git stash/은 git stash pop그것을 쉽게하고 병합에 대한 커밋되지 않은 변경 내용을 무시하는 것을 명시한다.