git / mercurial / bazzr 시스템이 중앙 집중식 시스템 (subversion, perforce)보다 나은 비즈니스 이유를 검색하지 못했습니다 .

당신은 DVCS를 제공 할 것을 인수 비 기술적 인 사람에게 DVCS를 판매하려고 한 경우 이익 증가 .

곧 관리자에게 git을 던질 것입니다 .subversion 저장소를 변환하고 smartgit 라이센스를 구입하는 데 약간의 시간이 걸립니다.

편집 이 질문을 중앙 집중식과 분산 형에 대한 일반적인 토론으로 만들려고했지만 필연적으로 git vs subversion으로 바뀌 었습니다. 확실히 Subversion보다 중앙 집중식 시스템이 더 좋습니다.

흠, 매니저로서 나는 이것에 대한 두 개의 즉각적인 "무릎 찌르기"반응이 있습니다.

• 아직 합당한 이유가 없다면 왜 최신 유행 이외의 git을 투구하고 있습니까?
• 마찬가지로 Subversion은 어떻게 교체가 필요합니까?

나는 실제로 부정적인 것이 아닙니다-아마도 상황에 따라 달라질 수 있다고 생각합니다. 그러나 만약 git이 subversion보다 "더 나은"것이라면, 실제로는 없습니다.

또한 마이그레이션 및 도구 변경의 오버 헤드를 이미 식별 한 단점을 열거 할 수 있어야합니다. 다른 문제는 무엇입니까? 예를 들어, 중앙 집중식 백업 저장소는 어떻게 되나요? 지속적인 통합 빌드 서버와 어떻게 통합합니까 (없는 경우 git을 잊어 버리고 먼저 정렬하십시오). 보안 및 추적-SVN은 적절한 로그인 및 권한으로 실행됩니다.

내 생각에 이점은 유연성, 더 나은 병합, 빌드를 중단하지 않고 로컬 커밋을 수행하는 기능에 있습니다. 단점은 제어력이 부족하고 유연성이 동일하다는 것입니다.

"더 나은"서브 버전 클라이언트로 머신에 로컬로 git을 실행하기 만하면됩니다 (수은을 사용하여이 작업을보고 있습니다).

흠, 아마도이 전체 답변은 실제로 주석입니까? 당신은 당신의 케이스를 만들 필요가 여기에 우리는 당신이 비즈니스 사례를 식별 할 수 있는지 확인하기 위해 (사용자 환경) 파괴를 통해 자식을 위해 (질문에).

FWIW, 나는 저장소의 특정 인스턴스를 트렁크 / 참조 소스로 쉽게 지정할 수 있다는 것을 알고 있으며, 더 나아가 관리 서버보다 DVCS를 사용하는 것보다 차이점이 있습니다. 아키텍처 고유의 무언가.

빠르고 새로운 분기 및 병합을 통해 개발자는 모든 새로운 기능을 분기 한 다음 나중에 병합 할 수 있으므로 코드를보다 생산적으로 활용할 수 있다고합니다. 개발 과정이 훨씬 순조롭게 진행됩니다. 또한 분산 특성으로 인해 모든 개발자가 전체 코드 사본을 보유 할 수 있으므로 모든 코드를 다운시키는 중앙 서버 오류에 대해 걱정할 필요가 없습니다. 그러나 Git을 사용하는 가장 큰 이유는이 두 가지 이유 일 것입니다.

개발자가 혼자 작업하는 경우에도 버전 제어를 통해 생산성을 높이고 (따라서 수익을 올릴 수 있음) 가정 할 수 있습니다.

우수한 DVCS는 팀의 일원으로 일할 때도 동일한 생산성 이점을 인식합니다. 각 개발자는 버전 제어 작업의 모든 이점을 얻을 수 있습니다. 다른 개발자가 변경 사항을 푸시 할 준비가 될 때까지 수행하는 작업.

• 버그 당 분기
• diff의 대기 시간이 줄어 듭니다.
• 할 수있는 매우 당신이있는 거 피어가 검토 할 때 분기의 역사를 통해 빠르게 탐색 임의로.
• 중앙 집중식 서버에 액세스 할 수없는 경우에도 전체 기록에 액세스 할 수 있습니다. 사무실에 있지 않고 전원이 꺼졌지만 랩톱의 배터리가 계속 작동하는 등 ...

이러한 것들을 통해 솔로와 팀 모두에서보다 효율적으로 작업 할 수 있습니다. 보다 효율적인 작업 = 개발 시간 단축 = 시장 출시 시간 단축 = 수익.

내 블로그에 링크 해 주신 것을 용서해주십시오. 그러나이 주제에 관한 기사를 작성했습니다.

• 팁이 항상 컴파일되어야하는 이유
• DVCS가 더 나은 중앙 제어를 제공하는 이유
• DVCS로 분기가 더 나은 이유
• 왜 분산 분기 모델은 CVCS 잘 작동하지 않을 수 있습니다 .

관련성이없는 경우 자유롭게 투표하십시오.

간단히 말해서 DVCS는 브랜칭 모델을 쉽게 만들어 많은 개발자 그룹이 서로 발끝을 밟지 못하게하여 생산성과 일일 빌드 품질을 모두 향상시킵니다. 버전 리포지토리의 복잡한 공동 작업은 로컬 리포지토리에서 수행 할 수 있으므로 중앙 리포지토리가 더 깨끗하고 고품질입니다. 또한 지사에 대한 결정은 효율성에 큰 영향을 줄 수 있습니다. 예를 들어 한 부서가 1.0을 다른 부서에서 정리하고있을 때 2.0에 대한 작업을 시작할 준비가 된 경우입니다. DVCS를 사용하면 이러한 결정을위원회가 아닌 로컬 수준에서 수행 할 수 있습니다.

DVCS에 대한 나의 주장은 다음과 같습니다.

• 분기가 끊어지지 않아 기능 개발 및 기존 제품 패치 유지시 마찰이 줄어 듭니다. 마찰 비용은 시간이 걸립니다.

• 최신 시스템으로 전환하면 최첨단 개발자가 더 많이 끌어 들여 더 나은 제품 문화가 생겨 비즈니스가 더 많은 제품을 판매 할 수있게됩니다.

• 네트워크가 아닌 커밋이 더 빠르기 때문에 개발자가 자주 커밋하여 세밀한 버그 감지 및 분석을 수행 할 수 있습니다.

본질적으로 마찰을 줄이는 것입니다. Muda 라는 용어가 있습니다 . 마찰이 많을수록 더 많은 고통을 겪습니다. 고통이 많을수록 더 적은 이익을 얻습니다.

내가 돋보이는 것에 대해 사과하지만, 불확실한 조건으로 비즈니스 사례를 제시 할 수 있습니다.

SVN은 개발자의 삶을 비참하게 만듭니다 . 그리고 그것은 소프트웨어 사업을 비참하게 만듭니다.

... 많은 사람들이 DVCS를 사용하기 시작할 때까지 깨닫지 못하는 방식으로. 이것은 가능한 가장 중요한 비즈니스 사례입니다 . 왜? 음, 좋은 개발자를 발견하고 유지하는 비용에 비해 DVCS로 전환 비용은 거의 존재하지 않는 것입니다 .

다음을 고려하세요:

• SVN (및 대부분의 다른 CVCSe)에서 가장 사소한 작업을 제외한 모든 작업에는 네트워크 액세스가 필요합니다. 대부분의 DVCS에서 네트워크 액세스는 push또는 pull작업 을 수행 할 때만 발생합니다 . 이는 사소한 명령이 느리다 는 것을 의미합니다 . 명령이 영원히 걸릴 때 당신은 무엇을합니까? 나는 기다리는 동안 개인적으로 programmers.se 또는 해커 뉴스를 탐색합니다. 간단히 말해, DVCS를 사용하면 프로그래머가 회사 소프트웨어를 작성하는 등 자신이 좋아하는 일에 집중할 수 있습니다 .
• SVN은 감옥에서 샤워 시설에 비누를 떨어 뜨릴 수 있도록 지원하는 것과 거의 같은 방식으로 분기를 지원합니다. 따라서 SVN은 개발자들이 끊임없이 서로 싸우면서 변화를하도록 강요합니다 .
• SVN이 다운되면 다운됩니다. 개발자가 전혀 할 수 없다면 일을하는 것이 몹시 어려워집니다. 따라서 SVN은 개발자가 100 % 버그가없는 인프라에 의존하도록합니다 .
• 요즘 git은 빠르게 정신을 공유하고 SVN은 빠르게 잃고 있습니다. SVN보다 DVCS를 사용하는 데 이점이 없다면 왜 프로그래밍 커뮤니티가 가능한 빨리 변경됩니까?

이 모든 것이 무엇입니까? DVCS에 정직한 시도를 한 개발자에게 아직 SVN을 선호하는 개발자를 만나지 못했습니다. 내가 더 성가신 대담한 진술을 할 수 있다면 SVN은 개발자들이 스스로 사용하도록 강요하는 "필요한 악"이다. Git은 개발자를보다 생산적이고 행복하게 만드는 도구입니다 .

(굵은 글씨는 당신이 중점을 두어야 할 구체적인 내용이라는 것을 지적해야합니다. 나머지는 단지 맥락을 제공합니다.)

내가 생각할 수있는 유일한 것은 git이 네트워크 연결없이 작동한다는 것입니다. 다른 모든 것들은 종종 오랜 시간 동안 침수 또는 퍼 포스를 사용하는 기술 사용자에게 판매하기가 어렵습니다.

문제가 생겼을 때의 차이 쇼

우리는 10 년 전의 저장소를 이식 한 후 6 개월 전에 자식으로 전환했습니다.

지금까지 약간의 실험을 거쳐 다음을 발견했습니다.

• 분기 및 병합은 거의 고통이 없습니다. 이를 통해 서로 발가락을 밟지 않고도 별도의 기능과 버그 수정 작업을 훨씬 쉽게 수행 할 수 있습니다. 또한 특정 버그 수정을 다른 곳에 적용하는 것도 매우 쉽습니다.

• 설계 상보다 견고 함-사용 가능한 중앙 서버에 100 % 의존하지 않으며, 그렇지 않은 경우 임시 복제본을 임시 교체로 임시로 사용할 수 있습니다. 이것은 중대한 실패 지점을 제거합니다. 어떤 이유로 든 SVN 서버가 다운되면 아무도 SVN 작업을 수행 할 수 없습니다. 어떤 이유로 든 중앙 git 리포지토리가 다운 된 경우에도 커밋이 복제되도록 로컬에서 작업 및 푸시 / 풀할 수 있습니다. 이 목적을 위해 여러 개의 오프 사이트 리포지토리를 가질 수도 있습니다.

• 저장소 상호 작용이 단순화되었습니다. CVS의 경우 정보가 필요할 때마다 항상 액세스해야했습니다. 자식의 경우 전체 저장소를 로컬에서 사용할 수 있으므로 많은 작업을 더 빠르게 수행 할 수 있습니다.

따라서 이점은 일상 생활에서 그다지 중요하지 않지만 올바르게 작동하지 않는 순간이 매우 분명합니다!

따라서 비즈니스 사례의 경우 재난 발생시 수행 할 작업을 살펴 ​​보는 것이 좋습니다.

브랜치 및 병합의 용이성은 가장 확실한 이유이지만 누군가를 설득하여 그것이 어떻게 개선되는지에 대한 구체적인 예를 제시해야합니다.

앱의 성능 향상을 위해 노력하는 프로그래머가 몇 명 있는데 실험 단계에 있으며 작성중인 코드가 마스터 / 트렁크 브랜치의 일부인지 여부를 모릅니다. 그러나 그들은 종종 서로 코드를 공유하고 막 다른 아이디어를 시도해야합니다. Subversion에서 이러한 빈번한 분기 및 병합을 어떻게 관리합니까? 짧은 대답은 당신이하지 않는 것입니다. dvc를 사용하면 정말 쉽습니다. 프로그래머는 새로운 아이디어를 신속하게 시도하고 다른 아이디어를 공유하기 전에 다른 아이디어를 공유 할 수 있습니다.

SubVersion을 버리는 비즈니스 사례는 분기 지원이 제품 안정화 및 유지 관리에 대한 장벽이라는 것입니다. 제품을 출시 한 다음 개발을 계속해야 할 경우 지점이 필요합니다. Subversion을 사용하면 개발자는 분기를 올바르게 사용하지 않으므로 벙크에 대한 개발을 유지하지 못하고 실제로 버그 수정으로 트렁크와 분기 모두에 해당 버그를 수정해야합니다.