기존 팀을위한 분산 버전 관리를 사용하는 두통?

개인 프로젝트에 DVCS를 사용하고 좋아하지만 다른 프로젝트에서 프로젝트에 대한 기여를 쉽게 관리하는 방법을 완전히 볼 수 있지만 (예 : 일반적인 Github 시나리오) "전통적인"팀의 경우 문제가있을 수 있습니다. TFS, Perforce 등의 솔루션에 의해 사용되는 중앙 집중식 접근 방식 ( "전통")은 사무실에서 한 사람이 소유하지 않은 한 프로젝트에서 작업하는 모든 개발자가 같은 코드를 사용하는 것을 의미합니다.

내가 직접 본 두 가지 문제가 있지만 다른 고려 사항을 들으십시오.

기존 시스템에서 서버에 대한 변경 사항을 확인하려고 할 때 다른 사람이 충돌하는 변경 사항을 이전에 체크인 한 경우이를 체크인하기 전에 병합해야합니다. DVCS 모델에서 각 개발자는 로컬로 변경하고 어떤 시점에서 다른 저장소로 푸시합니다. 해당 리포지토리에는 해당 파일의 분기가 있으며 2 명이 변경되었습니다. 이제는 그러한 상황을 처리 할 책임이있는 사람이있는 것 같습니다. 팀의 지정된 사람은 모든 충돌을 병합 할 수있는 전체 코드베이스에 대한 지식이 충분하지 않을 수 있습니다. 이제 누군가 개발자 중 한 명에게 접근하여 병합을 수행 한 다음 다시 푸시하도록 추가 단계를 추가했습니다 (또는 해당 작업을 자동화하는 인프라를 구축해야 함).

또한 DVCS는 로컬에서 작업하는 것이 매우 편리해지기 때문에 개발자가 푸시하기 전에 로컬 리포지토리에 약간의 변경 사항을 누적하여 이러한 충돌을보다 일반적이고 복잡하게 만들 수 있습니다.

분명히 팀의 모든 사람이 코드의 다른 영역에서만 작동한다면 문제가되지 않습니다. 그러나 모든 사람이 동일한 코드를 사용하는 경우가 궁금합니다. 중앙 집중식 모델 세력이 신속하고 빈번하게 처리되는 것처럼 보이며, 대규모의 고통스러운 합병을 수행하거나 누군가가 주요 리포지토리를 "경찰"해야 할 필요성을 최소화합니다.

따라서 사무실에서 팀과 함께 DVCS를 사용하는 사람들은 그러한 사례를 어떻게 처리합니까? 일일 (또는 주당) 워크 플로가 부정적인 영향을 받습니까? 직장에서 DVCS를 추천하기 전에 알아야 할 다른 사항이 있습니까?

우리는 약 1 년 동안 Mercurial을 사용해 왔습니다. 지금까지 언급 한 두통이 있지만 지금까지 우리를 위해 완전히 채택하기위한 가장 큰 과제는 로컬 리포지토리의 DVCS 사고 방식 (= 커밋이 자주 발생했습니다)이었습니다. 가기.

당신은 말했다 :

DVCS 모델에서 각 개발자는 변경 사항을 로컬에서 확인하고 어느 시점에서 다른 리포지토리로 푸시합니다. 해당 리포지토리에는 해당 파일의 분기가 있으며 2 명이 변경되었습니다. 이제는 그러한 상황을 처리 할 책임이있는 사람이있는 것 같습니다.

Mercurial의 기본 설치는이 동작을 차단합니다. 추가 확인없이 원격 리포지토리에 헤드가 두 개 이상 생성되면 푸시를 허용하지 않습니다. 우리는 매일의 활동을 피합니다. (Git은 heads라는 이름을 가지고 있으며 추가 확인없이 이전 버전을 완전히 병합 한 경우에만 업데이트 할 수 있으므로 상황이 다시 발생할 수 없습니다. 다른 DVCS도 비슷한 보호 기능을 가지고 있습니다.)

따라서 매일 업무가 끝나면 커밋을 위해 시간을 따로 떼어 놓아야합니다. 실제로는 다음과 같은 활동입니다.

1. 로컬 변경 사항을 커밋하십시오.
2. 중앙 저장소에서 당깁니다.
3. 병합 (& 커밋 병합)
4. 중앙 저장소로 푸시하십시오.

이렇게하면 최근이 코드를 작업 한 사람에 대한 병합 활동이 유지되며 변경 사항을 다른 사람처럼 신속하게 통합 할 수 있어야합니다.

질문에서 지적했듯이 두 사람이 동일한 코드 영역에서 작업 할 때 실제로 노력을 추가합니다. 이 경우 DVCS를 사용하면 더 많은 이점이 있으므로 해당 개발자에게는 이미 그 결과가 분명합니다. (추가 혜택에는 각 개발자가 별도의 코드를 커밋하고 다른 개발자가 방해하지 않고 자신의 리포지토리와 함께 플레이 할 수 있다는 점이 포함됩니다.)

언급 한 다른 문제 :

또한 DVCS는 로컬에서 작업하는 것이 매우 편리해지기 때문에 개발자가 푸시하기 전에 로컬 리포지토리에 약간의 변경 사항을 누적하여 이러한 충돌을보다 일반적이고 복잡하게 만들 수 있습니다.

이로 인해 병합 문제가 발생하지는 않지만 다른 문제가 발생할 수 있습니다.

DVCS의 유연성은 다양한 워크 플로가 가능하지만 그 중 일부는 무책임하다는 것을 의미합니다. DVCS를 사용하면 명확한 프로세스 나 절차가 필요합니다. 지역 변경을 유지하는 활동은 여러 가지에 따라 적절하거나 적절하지 않을 수 있습니다.

예를 들어, 개발자가 몇 주 동안 여가 시간에 애완 동물 기능을 작업 할 수 있습니까? 일부 환경에서는 이것이 권장되며, 일부 환경에서는 부적절하며 모든 변경 사항을 곧 중앙 집중화해야합니다. 그러나 개발자가 로컬에서 변경 사항을 유지하는 경우 관련 변경 사항을 가져 와서 최신 공통 버전으로 작업이 계속 잘 수행되도록해야합니다.

고무가 도로에 도달하면 소프트웨어 릴리스 또는 배포는 일반적으로 중앙 저장소에서 제공되므로 개발자는 테스트 및 배포를 위해 변경 사항을 가져와야합니다.

그건 내 이야기이고, 적어도 몇 분 동안 고집하고 있습니다 ...

귀하의 질문의 전제는 "병합이 어렵고 피해야합니다"에 관한 것 같습니다. DVCS 시스템은 이러한 장벽을 없애고 실제로 더 많은 것을 합병한다는 아이디어를 받아들입니다. 결과적으로 병합 및 병합 충돌에 대해 두려워하지 않아야합니다. 결과적으로 중앙 집중식 도구와 달리 DVCS 도구는 설계에 의해 지원됩니다.

Jamie F의 탁월한 답변-Commit-Pull-Merge-Push의 작업 흐름은 정기적으로 (매일) 수행됨에 따라 다른 작업을 걷고 있으면 볼 수있는 한 빨리 볼 수 있음을 의미합니다. .

설명하는 문제는 도구를 사용하도록 선택하는 방법에 대한 것입니다.

SVN과 GIT를 2 년 동안 로컬로 사용한 후 6 개월 전에 SVN에서 GIT로 전환했습니다. 아무도 돌아갈 수 없으며 고통스러운 병합 충돌은 과거의 일입니다. "작고 자주 커밋"만트라가 핵심입니다.

내가 자식을 사용하는 팀에서 일할 때의 경험의 원칙은 다음과 같습니다. 개인 지점에서 작업 한 다음 나머지 팀에서 작업을 수행 할 준비가되면 지점을 마스터에 리베이스하여 푸시하십시오. 그런 다음 지점을 확인하십시오.

이 전략은 마스터가 일련의 커밋이며, 모든 통합 문제가 공개되기 전에 지점에서 복구되었음을 의미했습니다.

SVN과 같은 도구는 긴밀하게 통합 된 작업 방식을 권장합니다.

즉, 공유 브랜치 (트렁크 또는 개발 브랜치)에 자주 커밋합니다.

이것은 내가 경험 한 대부분의 기업 개발 환경에서 A-OK이며 광범위한 통합 테스트, 회귀 테스트 및 단위 테스트에서 지원하는 Continuous Integration의 사용을 통해 더욱 촉진되고 권장됩니다. 그들의 변화에 ​​의한 것).

DVCS는 일부 상황에서 필요로하는보다 독립적으로 작업 할 수있는 자유를 제공하며 병합에 대한 (많은) 개선 된 지원은 어떠한 영향도 미치지 않습니다.

항상 내 마음 뒤에 머무르는 걱정은 이것입니다. 큰 자유와 함께 그 자유를 사용하려는 유혹이옵니다.

확실히, (제한된) 경험에서, 나는 이전 역할 (SVN, CVS & P4를 사용한 곳)보다 현재 팀 (머큐리얼을 사용)에서 독립적으로 일하는데 더 많은 시간을 보냅니다.

이것은 부분적으로 도구에 기인 한 것이지만, 의사 소통과 조정에 노력을 기울여야 할 강력한 이유가 없다면 사람들은 별개로 일하는 경향이 있다는 것이 합리적인 관찰이라고 생각합니다.

이것은 반드시 나쁜 것은 아니지만 고려해야 할 사항이라고 생각합니다.

git / mercurial 유형 버전 제어 기능은 자주 커밋하고 코드가 좋을 때 중앙 서버로 푸시하는 것입니다. 이것의 큰 장점 중 하나는 작은 패치를 만들어 충돌의 경우에 쉽게 적용 할 수 있다는 것입니다. 또한 워크 플로는 다음과 같은 라인에 있어야합니다.

1. 많은 지역 커밋
2. 서버에서 당겨
3. 서버로 푸시

서버에서 가져온이 충돌로 인해 충돌이 발생할 수 있지만이를 해결하기 위해 많은 시간이 필요한 것은 병합이 아닌 간단한 리베이스입니다. 이것은 주된 역사를 아주 깨끗하게 유지하고 많은 갈등을 제거 할 것이라고 생각합니다.

두 가지 일이 발생할 수 있으므로 동료의 로컬 리포지토리에서 가져 오는 경우에도 마찬가지입니다. 이미 패치를 가지고 있고 충돌이 발생하지 않기 때문에 서버로 먼저 푸시합니다. 또는 먼저 푸시합니다. 즉, 패치를 당길 때만 패치를 가져옵니다.

물론 마스터로 병합해야하는 기능 분기에서 작업하는 경우 예를 들어 병합이 더 나은 솔루션 인 경우도 있습니다.

워크 플로에서 다른 개발자에게 명시 적으로 이동하여 충돌을 해결하도록 지시해야하는 사람들에 대해 이야기하고 있지만 반드시 그럴 필요는 없습니다. 중앙 서버는 "보스"이며 주로 작업해야하는 대상입니다. 변경 사항이 중앙 저장소에 적용되면 괜찮습니다. 그렇지 않은 경우 충돌을 해결하는 것이 귀하의 임무입니다. 충돌하는 개발자는 자신의 변경 사항을 이해하는 데 도움이 될 수 있습니다. 서버에서 끌어 당기거나 리베이스하려고 할 때 표시되는 것입니다. 따라서 커밋하고 서버에서 가져와야 할 때 충돌을 해결하십시오.

중앙 집중식 저장소를 사용하는 원리는 비 잠금 중앙 집중식 또는 분산 시스템을 사용할 때와 동일합니다.

• 중앙 집중식 시스템에서 :
  1. 메인 라인에서 최신 버전을 가져옵니다 (subversion의 "trunk", git의 "master"등).
  2. 파일 수정
  3. "update"명령을 사용하여 메인 라인에서 최신 버전으로 수정 사항 병합
  4. 메인 라인에 전념
• 분산 시스템에서 :
  1. 메인 라인에서 최신 버전 받기
  2. 파일 수정
  3. 로컬 커밋
  4. 메인 라인에서 최신 버전으로 수정 사항을 병합하고 결과를 로컬로 커밋
  5. 메인 라인으로 푸시합니다.

분산 버전이 없으면 이전 헤드 개정판을 완전히 병합하지 않는 개정판을 푸시 할 수 있습니다 (특별한 재정의없이; 때로는 유용합니다), 병합 단계를 수행하지 않고는 통과하지 않으므로 누군가 두 가지 버전이 없습니다. 우려하는대로 강화해야합니다.

이제 용어를 제외하고 네 단계가 동일하지만 분산 시스템은 "3. 로컬 커밋"단계를 추가합니다. 이 단계의 가장 큰 장점은 업데이트 / 풀이 충돌을 일으키고이를 해결하거나 실수를 해결하는 방법을 모를 때 되돌아 가서 수행 한 작업을 검토하고 병합을 다시 실행할 수 있다는 것입니다. Subversion은 그중 어떤 것도 기억하지 못하므로 업데이트를 해결하는 실수를 저지르면 망하게됩니다.

변화가 누적되는 경우 사람들은 중앙 집중식 시스템으로도 변경하는 경향이 있습니다. 특히 기능을 자주 전환해야하는 경우 (버그를 해결하기 위해 더 긴 작업을 중단하거나 고객이 긴급하게 요구하는 조정을 수행하는 등) 사람들은 종종 완료되지 않았기 때문에 로컬에서 변경 사항을 유지해야합니다. 따라서 시스템이 적어도 그것을 이해하도록 지원하는 것이 좋습니다.

두 경우 모두 도구가 아닌 팀의 적절한 지침과 커뮤니케이션을 통해 이러한 문제를 해결해야합니다. 보다 유연한 도구를 사용하면 지침이 더 중요하지만,보다 유연한 도구를 사용하면 다양한 코너 케이스를보다 잘 처리 할 수 ​​있습니다.