회사의 버전 관리 시스템을 선택하고 싶습니다. 지금까지 Git, Subversion 및 Mercurial이 있음을 알고 있습니다.
요즘에는 Git이 가장 많이 사용되는 것을 보았으므로 여전히 Subversion을 사용해야하는 특별한 이유가 있습니까? 아니면 Git으로 직접 가야합니까?
회사의 버전 관리 시스템을 선택하고 싶습니다. 지금까지 Git, Subversion 및 Mercurial이 있음을 알고 있습니다.
요즘에는 Git이 가장 많이 사용되는 것을 보았으므로 여전히 Subversion을 사용해야하는 특별한 이유가 있습니까? 아니면 Git으로 직접 가야합니까?
답변:
SVN은 전혀 죽지 않았습니다. 그것은 여전히 매우 광범위하게 사용되며 언제 어디서나 가지 않을 것입니다. SVN은 특히 분산 버전 제어 가 필요한 분산 프로젝트를 실행하지 않는 경우 분산 버전 제어보다 사용이 훨씬 간단합니다 .
중앙 저장소가 하나 뿐인 경우 (여전히 소스 제어없이 얻을 수있을 정도로 회사 규모가 작을 경우 회사에서 필요한 모든 것) SVN을 사용하여 상호 작용하는 것이 훨씬 간단합니다. 예를 들어 SVN을 사용하면 단일 작업으로 저장소에서 변경 사항을 가져 오거나 로컬 변경 사항을 커밋 할 수 있지만 HG와 Git은 동일한 작업을 수행하기 위해 2-3 단계가 필요합니다.
그리고 최근 개정으로 SVN은 사람들이 HG와 Git을 선호하게 만드는 많은 성능 문제를 해결했습니다. 몇 년 전보다 훨씬 빨라졌으며,이 시점에서 실제로 분산 버전 제어의 고급 기능이 필요하지 않으면 프로젝트의 HG 또는 Git을 살펴볼만한 이유가 없습니다.
클라이언트 툴링은 아직 언급되지 않았습니다. 커맨드 라인 스크립트로 모든 것을 확실히 할 수는 있지만 GUI 통합을 통해 생산성을 크게 높일 수 있습니다.
우리는 주로 Visual Studio를 사용합니다. IDE에 통합하는 것은 현재 Git보다 SVN을 사용하는 것이 좋습니다. 향후에는 변경 될 수 있지만 버전 제어 기능만큼 결정에 영향을 미치게됩니다.
다른 모든 것과 마찬가지로, 버전 제어 시스템 자체도 목표가 아니라 어디로 가든지 확인할 수있는 도구입니다. 상황에 따라 가장 빨리 도착할 곳을 선택하십시오.
나는 힘내 팬이다. 최근 Git의 단점 중 하나는 svn의 릴리스 번호와 반대로 해시가있는 버전을 식별한다는 것입니다. 릴리스 번호는 전화 등으로 쉽게 전달할 수 있습니다.
그리고 그것은 내가 상상할 수있는 유일한 프로입니다. 이 기능에 정말로 의존하고 싶다면 분산 및 / 또는 중앙 집중식 VCS Bazaar 에서 사용할 수 있습니다 . Git에는 목적을 달성 할 수있는 태그가 있습니다.
어쨌든 나는 빠른 지점 전환과 숨김없이 개발을 상상할 수 없었습니다. 이 두 가지 기능만으로 SVN을 능가했습니다. 여기까지 동일한 목표를 달성하기 위해 전체 트리를 별도의 디렉토리로 만들고 체크 아웃 해야하는 동일한 작업을 기억합니다.
이른바 "분산 버전 제어의 고급 기능"에는 시간이 함께 제공되므로 처음부터 배울 필요가 없습니다. 그들을 두려워하지 마십시오. 그들은 방해하지 않기 위해 당신을 돕기 위해 여기 있습니다. 그리고 DVCS를위한 중앙 저장소를 설정하는 데 아무런 문제가 없습니다.
SVN을 사용하면 리포지토리의 일부를 폴더 수준으로 쉽게 체크 아웃 할 수 있지만 git을 사용하면 모든 기록을 포함하여 전체 리포지토리를 얻을 수 있습니다.
상황에 따라 SVN에 이점이있을 수 있습니다.
(또한 폴더 트리까지 숨겨진 ".svn"가비지와 같은 큰 단점이 있습니다.
"6 시간 동안 수행 할 수있는 작업이 있다면 6 시간이 걸리더라도 도구를 작성하는 것이 20 분 안에 작성하는 것이 더 낫습니다."
분산 버전 제어는 해결해야 할 다른 짐승입니다. 각 개발자마다 상당한 학습이 필요합니다. 각 개발자의 학습 프로세스를 수용 할 수있는 버퍼가있는 경우 적절한 분산 버전 제어 시스템으로 이동해야합니다. 학습 단계가 완료되면 분산 버전 제어가 중앙 집중식 버전 제어보다 훨씬 낫습니다.
분산 버전 제어는 최종적인 것으로 보입니다. 오랫동안 머무르는 것이 여기에 있습니다. 나중에 빨리 적응하는 것이 좋습니다. SVN이 새롭고 사람들이 CVS에 익숙해 졌을 때 SVN을 사용하지 않는다는 주장이 많이 있었지만 SVN이 가장 인기있는 버전 제어 시스템이 된 것과 같은 토론을 기억합니다.
회사가 기존 버전 제어 시스템에서 많은 소스 코드로 잘 설립 된 경우 새 시스템으로 이동하는 것은 큰 작업이지만 회사가 작거나 시작하는 경우 새 버전 제어로 이동하는 것은 매우 쉽습니다. 그러나 이전 버전 컨트롤 (새 설정)을 고수하면 나중에 버전 컨트롤 마이그레이션을 계획해야하는 병목 현상이 발생할 수 있습니다.
나는 많은 SVN 의견을 보았지만, 모두 "SVN이 더 낫다"보다는 "SVN이 나쁘지 않다"는 경향이있다. 따라서 프로젝트에 대해 분산 버전 제어 (예 : Git)를 선택하는 것이 좋습니다.
SVN에 비해 GIT의 장점 편집
누군가가 SVN을 고수하는 이유로 툴링 (Visual Studio 용)을 언급했습니다. http://gitscc.codeplex.com/ 은 Visual Studio에 대한 GIT 지원을 제공합니다.
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.
나는 이것에 완전히 동의하지 않습니다. 상황에 따라 인식되는 이점이있을 수 있지만 svn의 사람이 읽을 수있는 버전 번호만큼 간단한 것은 많은 조직에서 큰 이점입니다.
그 당시 Subversion을 사용해야 할 특별한 이유가 있습니까?
IDE에서의 툴링 지원과는 별개로 (필자는 사용하지 않음) – 실제로는 아닙니다. 물론 SVN이 더 친숙 할 수도 있지만 이것이 유일한 이유에 대한 것이므로 Hg와 Git을 배우는 것이 매우 쉽고 빠릅니다.
그렇습니다. 브랜치가 힐버트 공간의 하위 매니 폴드를 매핑하는 동종 이형 endofunctors라는 것을 이해하면 Git이 얼마나 사소한지를 설명하는 모든 복잡한 가이드가 있습니다. 1
나는 그것을 이해하지 못한다. 그러나 당신은 무엇을 알고 있습니까? 중요하지 않습니다. Git을 사용하기 위해 그 어떤 것도 알 필요가 없습니다.
대부분의 경우 Git과 Hg는 사용하기 쉽고 SVN보다 확실한 이점이 있습니다. 방 안에있는 코끼리는 물론 가지가 있습니다 : 가지들은 Git과 Hg에서 작동합니다. 대조적으로, SVN에서는 그것들이 기껏해야 고통스럽고 최악의 경우에는 여러 머리를 병합합니다.
물론 SVN을 계속 사용할 수 있습니다. 여전히 Windows XP를 사용할 수도 있습니다. 그러나 두 가지를 모두 시도한 대부분의 사용자는 대안 중 하나가 상당히 우수하다는 데 동의합니다.
1 네, 농담입니다. 내 생각에