나는 몇 년 동안 Subversion 을 사용해 왔으며 SourceSafe 를 사용한 후에는 Subversion 을 좋아합니다. TortoiseSVN 과 결합하여 어떻게 그것이 더 나을 수 있는지 상상할 수 없습니다.
그러나 Subversion에 문제가 있으며 Git 과 같은 새로운 유형의 분산 버전 제어 시스템으로 옮겨야한다고 주장하는 개발자가 점점 늘어나고 있습니다 .
Git은 Subversion을 어떻게 개선합니까?
나는 몇 년 동안 Subversion 을 사용해 왔으며 SourceSafe 를 사용한 후에는 Subversion 을 좋아합니다. TortoiseSVN 과 결합하여 어떻게 그것이 더 나을 수 있는지 상상할 수 없습니다.
그러나 Subversion에 문제가 있으며 Git 과 같은 새로운 유형의 분산 버전 제어 시스템으로 옮겨야한다고 주장하는 개발자가 점점 늘어나고 있습니다 .
Git은 Subversion을 어떻게 개선합니까?
답변:
힘내는 Subversion보다 낫지 않습니다. 그러나 더 나쁘지 않습니다. 그것은 다르다.
중요한 차이점은 분산되어 있다는 것입니다. 이동 중에 개발자이고 랩톱에서 개발하고 3 시간 동안 되돌아 갈 수 있도록 소스 제어를 원한다고 상상해보십시오.
Subversion을 사용하면 문제가 있습니다. SVN 리포지토리가 회사에 연결할 수없는 위치에있을 수 있습니다 (현재 인터넷이없는 경우). 코드를 복사하려면 문자 그대로 복사 / 붙여 넣기해야합니다.
Git을 사용하면이 문제가 없습니다. 로컬 사본은 리포지토리이므로이를 커밋하고 소스 제어의 모든 이점을 얻을 수 있습니다. 기본 리포지토리에 다시 연결되면 커밋 할 수 있습니다.
이것은 처음에는 좋아 보이지만이 접근 방식에 추가 된 복잡성을 염두에 두십시오.
힘내는 "새롭고 반짝이는 멋진"것 같습니다. 그것은 결코 나쁘지 않습니다 (Linus가 결국 Linux Kernel 개발을 위해 그것을 쓴 이유가 있습니다). 그러나 많은 사람들이 "Distributed Source Control"열차가 실제로 새롭고 Linus Torvalds에 의해 작성 되었기 때문에 실제로는 왜 더 나은지 아는 것.
Subversion에는 문제가 있지만 Git, Mercurial, CVS, TFS 등이 있습니다.
편집 : 그래서이 답변은 이제 1 년이되었지만 여전히 많은 투표를 생성하므로 설명을 더 추가 할 것이라고 생각했습니다. 작년에이 글을 쓴 이후, Git은 특히 GitHub와 같은 사이트가 실제로 시작된 이후 많은 추진력과 지원을 받았습니다. 요즘에는 Git과 Subversion을 모두 사용하고 있으며 개인적인 통찰력을 공유하고 싶습니다.
우선, Git은 분산 작업을 할 때 처음에는 정말 혼란 스러울 수 있습니다. 리모컨이란? 초기 저장소를 올바르게 설정하는 방법은 무엇입니까? 처음에는 SVN의 간단한 "svnadmin create"와 비교할 때 두 가지 질문이 있습니다. Git의 "git init"는 매개 변수 -bare 및 --shared를 사용하여 중앙 집중식을 설정하는 "적절한"방법으로 보입니다. 저장소. 여기에는 이유가 있지만 복잡성을 더합니다. "checkout"명령의 문서화는 사람들이 바뀌는 것에 매우 혼란스러워합니다. "적절한"방법은 "git clone"인 것 같지만 "git checkout"은 분기를 바꾸는 것 같습니다.
Git REALLY는 탈 중앙화 될 때 빛납니다. 집에 서버가 있고 도로에 랩톱이 있으며 SVN은 여기서 제대로 작동하지 않습니다. SVN을 사용하면 저장소에 연결되어 있지 않으면 로컬 소스 제어를 할 수 없습니다 (예, SVK 또는 저장소를 복사하는 방법에 대해 알고 있습니다). Git에서는 이것이 기본 모드입니다. git commit origin master는 마스터 브랜치를 "origin"이라는 원격으로 마스터 브랜치를 푸시하는 반면 추가 명령입니다.
위에서 언급했듯이 Git은 복잡성을 추가합니다. 리포지토리 생성의 두 가지 모드, 체크 아웃 vs. 복제, 커밋 및 푸시 ... 로컬에서 작동하는 명령과 "서버"에서 작동하는 명령을 알아야합니다 (대부분의 사람들은 여전히 중앙 "마스터 리포지토리"를 가정합니다. ).
또한 최소한 Windows에서는 툴링이 여전히 충분하지 않습니다. 예, Visual Studio AddIn이 있지만 여전히 msysgit과 함께 git bash를 사용합니다.
SVN은 배우기가 훨씬 간단하다는 장점이 있습니다. 저장소를 만들고, 커밋하고 체크 아웃하는 방법을 알고 있고 갈 준비가되었고 나중에 분기, 업데이트 등과 같은 것을 가져올 수 있다면 저장소에 대한 모든 변경 사항이 있습니다. 의 위에.
Git은 일부 개발자가 항상 마스터 리포지토리에 연결되어 있지 않은 경우 훨씬 적합하다는 장점이 있습니다. 또한 SVN보다 훨씬 빠릅니다. 그리고 내가 듣는 것에서 지원을 분기하고 병합하는 것이 훨씬 나아졌습니다 (이것이 작성된 주요 이유이기 때문에 예상됩니다).
이것은 또한 Git이 오픈 소스 프로젝트에 완벽하게 적합하기 때문에 인터넷에서 왜 그렇게 화를 내는지 설명합니다. 그냥 포크하고 변경 사항을 자신의 포크로 커밋 한 다음 원래 프로젝트 관리자에게 변경 사항을 가져 오도록 요청하십시오. Git을 사용하면 작동합니다. 실제로 Github에서 사용해보십시오. 그것은 마술입니다.
또한 Git-SVN Bridges도 볼 수 있습니다. 중앙 저장소는 Subversion 저장소이지만 개발자는 로컬로 Git과 함께 작업하고 브리지는 변경 사항을 SVN으로 푸시합니다.
그러나이 긴 추가에도 불구하고 여전히 핵심 메시지를지지합니다. Git은 나쁘지 않습니다. 단지 다릅니다. "오프라인 소스 제어"가 필요하고 그것을 배우는 데 더 많은 시간을 할애한다면 환상적입니다. 그러나 엄격하게 중앙 집중식 소스 제어가 있거나 동료가 관심이 없기 때문에 소스 제어를 처음 도입하는 데 어려움을 겪고 있다면 SVN의 단순성과 우수한 툴링 (적어도 Windows에서는)이 빛납니다.
Git을 사용하면 모든 사람이 자신의 저장소를 가지고 있기 때문에 실제로 오프라인으로 무엇이든 할 수 있습니다.
브랜치를 만들고 브랜치를 병합하는 것은 정말 쉽습니다.
프로젝트에 대한 커밋 권한이 없더라도 온라인으로 자체 저장소를 보유하고 패치에 대한 "푸시 요청"을 게시 할 수 있습니다. 패치를 좋아하는 모든 사람은 공식 관리자를 포함하여 패치를 프로젝트에 가져올 수 있습니다.
프로젝트를 포크하고 수정 한 후에도 HEAD 브랜치의 버그 수정에 계속 병합하는 것은 쉽지 않습니다.
Git은 Linux 커널 개발자를 위해 일합니다. 그것은 정말 빠르며 (수행해야 함) 수천 명의 기여자에게 확장됨을 의미합니다. Git은 더 적은 공간을 사용합니다 (Mozilla 리포지토리의 경우 최대 30 배 더 적은 공간).
Git은 매우 유연하고 매우 TIMTOWTDI입니다 (하나 이상의 방법이 있습니다). 원하는 워크 플로를 사용할 수 있으며 Git에서 지원합니다.
마지막으로 Git 리포지토리를 호스팅하기에 좋은 사이트 인 GitHub 가 있습니다 .
힘내의 단점 :
다른 답변은 Git의 핵심 기능을 설명하는 데 도움이되었습니다. 그러나 Git이 더 잘 동작하고 내 인생을 더 깨끗하게 유지하는 데 도움이되는 작은 방법이 많이 있습니다. 다음은 몇 가지 작은 것입니다.
git mv및 git rm.
" Git이 X보다 나은 이유 "는 Git과 다른 SCM의 다양한 장단점을 설명합니다.
간단히:
몇 가지 단점이 있습니다.
가장 간단한 사용법에서 Subversion과 Git은 거의 동일합니다. 다음과 같이 큰 차이가 없습니다.
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
과
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Git이 실제로 빛나는 곳은 다른 사람들과 분기하고 협력하는 것입니다.
글쎄, 배포되었습니다. 벤치 마크는 상당히 빠르며 (분산 특성, diff 및 log와 같은 작업은 모두 로컬이므로 물론이 경우 엄청나게 빠릅니다) 작업 폴더는 더 작습니다 (여전히 마음이 아파요).
Subversion 또는 다른 클라이언트 / 서버 개정 관리 시스템에서 작업 할 때는 개정판 을 체크 아웃 하여 시스템에서 작업 사본을 작성해야합니다 . 리포지토리의 모양에 대한 스냅 샷을 나타냅니다. 업데이트를 통해 작업 복사본을 업데이트하고 커밋을 통해 리포지토리를 업데이트합니다.
분산 버전 제어를 사용하면 스냅 샷이 아니라 전체 코드베이스가 있습니다. 3 개월 된 버전으로 diff를 원하십니까? 문제 없습니다. 3 개월 이전 버전은 여전히 컴퓨터에 있습니다. 이것은 일이 더 빠르다는 것을 의미 할뿐 아니라 중앙 서버와의 연결이 끊긴 경우에도 이전에 사용하던 많은 작업을 수행 할 수 있습니다. 다시 말해, 주어진 개정의 스냅 샷이 아니라 전체 코드베이스가 있습니다.
Git이 하드 드라이브에서 많은 공간을 차지할 것이라고 생각하지만, 내가 본 몇 가지 벤치 마크에서 실제로는 더 적은 시간이 걸립니다. 방법을 묻지 마십시오. 내 말은, 그것은 Linus에 의해 지어졌으며, 내가 추측하는 파일 시스템에 대해 한두 가지 알고 있습니다.
DVCS에 대해 내가 좋아하는 요점은 다음과 같습니다.
비교적 큰 프로젝트의 주된 이유는 포인트 3에 의해 생성 된 커뮤니케이션이 향상 되었기 때문입니다. 다른 것들은 좋은 보너스입니다.
재미있는 점은 Subversion Repos에서 프로젝트를 호스팅하지만 Git Clone 명령을 통해 프로젝트에 액세스한다는 것입니다.
Google 코드 프로젝트에서 Git으로 개발을 읽으십시오.
Google 코드는 기본적으로 Subversion을 사용하지만 개발 중에 Git을 쉽게 사용할 수 있습니다. "git svn"을 검색하면이 방법이 널리 퍼져 있음을 시사하며 실험 해 보는 것도 좋습니다.
Svn 리포지토리에서 Git을 사용하면 다음과 같은 이점이 있습니다.
backup/public svn 저장소가 있습니다.여기에 모든 대답은 프로그래머 중심의 예상대로이지만 회사에서 소스 코드 외부에서 개정 제어를 사용하면 어떻게됩니까? 버전 제어의 혜택을받는 소스 코드가 아닌 다른 문서가 많으며 다른 CMS가 아닌 코드에 가깝게 살아야합니다. 대부분의 프로그래머는 독립적으로 일하지 않습니다. 우리는 팀의 일원으로 회사를 위해 일합니다.
이를 염두에두고 클라이언트 툴링 및 교육에서 Subversion과 git 간의 사용 편의성을 비교하십시오. 나는 어디에서 시나리오를 볼 수 없습니다 어떤 분산 버전 관리 시스템이 아닌 프로그래머로 사용하거나 설명하기 쉬울 것입니다을. 나는 git을 평가할 수 있고 실제로 프로그래머가 아닌 버전 제어가 필요한 사람들이 그것을 받아 들일 희망을 가지고 있기 때문에 잘못 입증되고 싶습니다.
그럼에도 불구하고 경영진이 중앙 집중식에서 분산 개정 제어 시스템으로 전환해야하는 이유를 묻는다면 필자가 필요하지 않기 때문에 정직한 답변을 제공하기가 어려울 것입니다.
면책 조항 : 나는 약 v0.29 초반에 Subversion에 관심을 갖게되었으므로 분명히 편견이 있지만 그 이후로 일한 회사는 그 사용을 장려하고 지원했기 때문에 열정으로 이익을 얻습니다. 나는 이것이 대부분의 소프트웨어 회사에서 일어나는 방식이라고 생각합니다. 너무 많은 프로그래머가 git bandwagon에 뛰어 들면서 소스 코드 외부에서 버전 제어를 사용하는 이점을 얼마나 많은 회사가 놓칠 지 궁금합니다. 팀마다 별도의 시스템이 있더라도 유지 관리, 하드웨어 및 교육 요구 사항이 증가하는 동안 (통합) 문제 추적 통합과 같은 몇 가지 이점이 빠져 있습니다.
Subversion은 여전히 훨씬 더 많이 사용되는 버전 관리 시스템이므로 도구 지원이 향상되었습니다. 거의 모든 IDE 용 성숙한 SVN 플러그인을 찾을 수 있으며 TurtoiseSVN과 같은 훌륭한 탐색기 확장 기능을 사용할 수 있습니다. 그 외에는 Michael 과 동의해야합니다 : Git은 Subversion보다 낫거나 나쁘지 않습니다.
Subversion / GIT에 관한 David Richards WANdisco 블로그
GIT의 출현으로 GIT 이외의 다른 것은 쓰레기라고 생각하는 일종의 DVCS 근본 주의자 인 'Gitterons'가 등장했습니다. Gitterons는 소프트웨어 엔지니어링이 자신의 섬에서 발생한다고 생각하는 경우가 많으며 대부분의 조직에서 선임 소프트웨어 엔지니어를 독점적으로 고용하지 않는 경우가 종종 있습니다. 괜찮습니다.하지만 나머지 시장의 생각은 아닙니다. 그리고 그것을 증명하게되어 기쁩니다. 마침내 GIT는 시장의 3 % 미만이었고 Subversion은 5 백만 명의 사용자와 약 절반의 지역에 있습니다. 전반적인 시장.
우리가 본 문제는 Gitterons가 Subversion에서 발사 (저렴한) 샷이라는 것입니다. “Subversion은 너무 느리고 [느린 / 크래프 / 제한적 / 냄새가 나지 않고 / 재미있는 방식으로 나를 본다] 그리고 지금은 GIT를 가지고 있고 [모든 인생에서 일하고 있습니다 / 아내가 임신했습니다 / 나중에 여자 친구가 생겼습니다. 30 년간의 시도 / 블랙 잭 테이블에서 6 번 뛰었습니다.]. 당신은 그림을 얻는다.
그것은 무엇을하기 위해 필요한 사용의 용이성 / 단계에 관한 것입니다.
PC / 노트북에서 단일 프로젝트를 개발하는 경우 설정 및 사용이 훨씬 쉽기 때문에 git이 더 좋습니다. 서버가 필요 없으며 병합 할 때 저장소 URL을 계속 입력 할 필요가 없습니다.
그것이 단지 2 명이라면, git도 더 쉽다고 말합니다. 왜냐하면 서로 밀고 당길 수 있기 때문입니다.
그 이상으로 넘어 가면 전복을 갈 것입니다.이 시점에서 '전용'서버 또는 위치를 설정해야하기 때문입니다.
SVN과 마찬가지로 git 에서도이 작업을 수행 할 수 있지만 중앙 서버와 동기화하기 위해 추가 단계를 수행해야하기 때문에 git의 이점보다 중요합니다. SVN에서는 커밋합니다. git에서는 커밋을 git push해야합니다. 추가 단계는 단순히 너무 많은 일을 끝내기 때문에 성가 시게됩니다.
SVN은 더 나은 GUI 도구의 이점을 가지고 있지만 git 생태계는 빠르게 따라 잡는 것처럼 보이므로 장기적으로 이것에 대해 걱정하지 않을 것입니다.
Git과 DVCS는 일반적으로 모든 사람이 자신의 브랜치를 가지고 있기 때문에 서로 독립적으로 많은 코딩을 수행하는 개발자에게 좋습니다. 그래도 다른 사람의 변경이 필요한 경우, 로컬 리포지토리에 맡겨야하고 해당 변경 집합을 사용자에게 푸시해야합니다.
나 자신의 추론으로 인해 중앙 집중식 릴리스와 같은 작업을 수행하면 DVCS로 인해 QA 및 릴리스 관리가 어려워집니다. 누군가는 다른 모든 저장소에서 푸시 / 풀을 수행하여 이전 커밋 시간에 해결 된 충돌을 해결 한 다음 빌드를 수행 한 다음 다른 모든 개발자가 리포지토리를 다시 동기화하도록해야합니다.
이 모든 것은 물론 인간의 프로세스로 해결할 수 있습니다. DVCS는 새로운 편의성을 제공하기 위해 중앙 집중식 버전 제어로 해결 된 문제를 해결했습니다.
실제로 Git은 중소 규모의 팀에서 커뮤니케이션 개발자와 개발자 간의 커뮤니케이션에 도움이되기 때문에 좋아합니다. 분산 버전 제어 시스템 인 푸시 / 풀 시스템을 통해 개발자는 단일 프로젝트에서 작업하는 대규모 개발자 풀을 관리하는 데 도움이되는 소스 코드 에코 시스템을 만들 수 있습니다.
예를 들어 5 명의 개발자를 신뢰하고 자신의 저장소에서 코드 만 가져옵니다. 각 개발자는 코드를 가져 오는 자체 신뢰 네트워크를 가지고 있습니다. 따라서 개발은 코드 책임이 개발 커뮤니티에서 공유되는 개발자의 신뢰 구조를 기반으로합니다.
물론 여기에 다른 답변에서 언급 된 다른 이점이 있습니다.
몇 가지 답변이 이것에 대해 암시되었지만 2 점을 명시 적으로 만들고 싶습니다.
1) 선택적 커밋을 수행하는 기능 (예 :) git add --patch. 작업 디렉토리에 동일한 논리적 변경의 일부가 아닌 여러 변경 사항이 포함 된 경우 Git을 사용하면 변경 내용의 일부만 포함하는 커밋을 매우 쉽게 수행 할 수 있습니다. Subversion을 사용하면 어렵습니다.
2) 변경 사항을 공개하지 않고 커밋 할 수있는 기능. Subversion에서는 커밋이 즉시 공개되므로 취소 할 수 없습니다. 이는 개발자가 "일찍 커밋하고 자주 커밋"하는 기능을 크게 제한합니다.
힘내는 단순한 VCS 이상입니다. 패치를 개발하는 도구이기도합니다. Subversion은 VCS 일뿐입니다.
Subversion은 괜찮다고 생각합니다. 병합을 시작하거나 복잡한 작업을 수행 할 때까지 또는 Subversion은 복잡한 작업을 수행합니다. 특정 파일을 엉망으로 만드는 브랜치를 찾기위한 쿼리 수행, 실제로 변경 이 발생한 위치, 복사 및 붙여 넣기 감지 등) ...
GIT 의 주요 이점 은 오프라인 작업 이라고 말하면서 당첨 된 답변에 동의하지 않습니다. 확실히 유용하지만 사용 사례에 대한 추가 기능과 같습니다. SVK는 오프라인에서도 작동 할 수 있지만 여전히 학습 시간에 투자해야 할 질문은 없습니다.)
그것은 매우 강력하고 빠르며 개념에 익숙해지면 매우 유용합니다 (그렇습니다, 그런 의미에서 : 사용자 친화적).
병합 이야기에 대한 자세한 내용은 다음을 참조하십시오 : git-svn (또는 비슷한) * 그냥 *를 사용하여 svn 병합에 도움이됩니까?
중앙 저장소의 물을 흐트러 뜨리지 않고 Git에서 소스 코드의 로컬 브랜치를 관리 할 수있는 것을 정말 좋아합니다. 대부분의 경우 Subversion 서버에서 코드를 체크 아웃하고 로컬 Git 리포지토리를 실행하여이 작업을 수행 할 수 있습니다. 또한 Git 리포지토리를 초기화해도 성가신 .svn 폴더로 파일 시스템을 오염시키지 않습니다.
Windows 도구가 지원하는 한 TortoiseGit은 기본 사항을 매우 잘 처리하지만 로그를 보지 않으려면 명령 줄을 선호합니다. 커밋 로그를 읽을 때 Tortoise {Git | SVN}이 돕는 방식이 정말 마음에 듭니다.
이것은 잘못된 질문입니다. git의 사마귀에 집중하고 적어도 일부 사용 사례에서 subversion이 표면적으로 더 나은 이유에 대한 논쟁을 공식화하는 것은 너무 쉽습니다. git은 원래 저수준 버전 제어 구성 세트로 설계되었으며 바로크 리눅스 개발자 지향 인터페이스를 통해 거룩한 전쟁에서 견인력과 합법성을 쉽게 알 수 있습니다. 힘내 지지자들은 수백만 가지의 워크 플로 이점으로 드럼을 강타하여 svn 사람들은 불필요하다고 선포합니다. 곧 전체 토론이 중앙 집중식 대 분산 형으로 구성되어 엔터프라이즈 svn 툴 커뮤니티의 이익을 제공합니다. 일반적으로 기업에서 Subversion의 우수성에 대해 가장 설득력있는 기사를 게시 한이 회사는
그러나 여기에 문제가 있습니다 : Subversion은 아키텍처 막 다른 골목 입니다.
svn이 git 에서뿐만 아니라 어디에서나 기본적인 병합 추적 작업을 수행 할 수 없었기 때문에 git을 가져 와서 중앙 집중식 서브 버전 교체를 아주 쉽게 만들 수는 있지만 svn은 약 2 배 이상 지속되었습니다. 이를위한 기본 이유 중 하나는 브랜치를 디렉토리와 동일하게 만들려는 디자인 결정 때문입니다. 왜 그들이 원래 이런 방식으로 갔는지 모르겠습니다. 부분 체크 아웃은 매우 간단합니다. 안타깝게도 기록을 제대로 추적 할 수 없습니다. 이제 분명히 하위 버전 저장소 레이아웃 규칙을 사용하여 분기를 일반 디렉토리와 분리하고 svn은 휴리스틱을 사용하여 일상적인 사용 사례에 효과적입니다. 그러나이 모든 것은 단지 매우 가난하고 제한적인 저수준 설계 결정에 대한 것입니다. 디렉토리 별 diff가 아닌 저장소 별 diff를 수행 할 수있는 기능은 버전 제어 시스템의 기본적이고 중요한 기능이며 내부를 크게 단순화하여 더 똑똑하고 유용한 기능을 구축 할 수 있습니다. Subversion을 확장하는 데 많은 노력을 기울 였지만 병합 해결과 같은 기본 작업 측면에서 현재 VCS의 현재 작물에서 얼마나 뒤떨어져 있는지 확인할 수 있습니다.
이제 Subversion이 가까운 미래에 충분하다고 생각하는 사람을위한 진심 어린 조언과 충고가 있습니다.
Subversion은 RCS와 CVS의 실수로부터 배운 새로운 VCS를 따라 잡을 수 없습니다. 리포지토리 모델을 처음부터 수정하지 않으면 기술적으로 불가능하지만 실제로는 svn되지 않습니까? 현대식 VCS의 기능이 없다고 생각하는 것과 무관하게, 무지는 당신이 Subversion의 함정에서 당신을 보호하지 않을 것입니다.
솔루션의 기술적 열 등성이 svn과 마찬가지로 명확하지 않다는 것은 극히 드문 일입니다. 확실히 win-vs-linux 또는 emacs-vs-vi에 대한 그런 견해를 밝히지 않을 것입니다. 명확하고 소스 제어는 개발자의 무기고에있어 매우 중요한 도구이므로 명확하게 언급해야한다고 생각합니다. 조직적인 이유로 svn을 사용해야하는 요구 사항에 관계없이 모든 svn 사용자는 논리적 인 사고 방식으로보다 현대적인 VCS가 대규모 오픈 소스 프로젝트에만 유용하다는 잘못된 믿음을 갖지 않도록 간청합니다. 개발 작업의 특성에 관계없이 프로그래머라면 Git, Mercurial, Darcs 또는 기타 여러 가지 등 더 나은 VCS를 사용하는 방법을 배우면 더 효과적인 프로그래머가 될 것입니다.
Subversion은 사용하기 매우 쉽습니다. 나는 지난 몇 년 동안 문제를 발견하지 못했거나 무언가가 예상대로 작동하지 않는다는 것을 결코 발견하지 못했습니다. 또한 우수한 GUI 도구가 많이 있으며 SVN 통합에 대한 지원이 큽니다.
힘내로 더 유연한 VCS를 얻을 수 있습니다. 모든 변경 사항을 커밋하는 원격 저장소에서 SVN과 같은 방식으로 사용할 수 있습니다. 그러나 대부분 오프라인으로 사용할 수 있으며 변경 사항을 원격 저장소로만 푸시 할 수도 있습니다. 그러나 Git은 더 복잡하고 학습 곡선이 가파 릅니다. 처음으로 잘못된 지점에 커밋하여 간접적으로 지점을 만들거나 실수에 대한 정보가 많지 않고 더 나은 정보를 얻으려면 Google을 검색 해야하는 위치에 오류 메시지가 표시됩니다. 마커 대체 ($ Id $)와 같은 일부 쉬운 기능은 작동하지 않지만 GIT에는 고유 한 스크립트를 병합 할 수있는 매우 유연한 필터링 및 후크 메커니즘이 있으므로 필요한 모든 것을 얻을 수 있지만 문서를 읽는 데 더 많은 시간과 읽기가 필요합니다 ;)
로컬 리포지토리에서 대부분 오프라인으로 작업하는 경우 로컬 시스템에서 무언가가 손실되면 백업이 없습니다. SVN을 사용하면 주로 다른 서버에서 백업하는 시간과 동일한 원격 저장소를 사용하고 있습니다 ... Git은 동일한 방식으로 작동 할 수 있지만 이것은 SVN2와 같은 것을 갖는 Linus의 주요 목표는 아닙니다. Linux 커널 개발자를 위해 설계되었으며 분산 버전 제어 시스템이 필요합니다.
Git이 SVN보다 낫습니까? 일부 버전 기록과 백업 메커니즘 만 필요한 개발자는 SVN을 사용하는 것이 좋습니다. 지점과 함께 일하거나 동시에 더 많은 버전을 테스트하거나 대부분 오프라인으로 작업하는 개발자는 Git의 기능을 활용할 수 있습니다. SVN에서는 찾을 수없는 숨김과 같은 매우 유용한 기능이있어보다 쉽게 사용할 수 있습니다. 그러나 다른 한편으로는 모든 사람들이 모든 기능을 필요로하는 것은 아닙니다. 그래서 나는 SVN의 죽음을 볼 수 없습니다.
Git에는 더 나은 문서가 필요하며 오류보고가 더 도움이되어야합니다. 또한 기존의 유용한 GUI는 거의 없습니다. 이번에는 대부분의 Git 기능 (git-cola)을 지원하는 Linux 용 GUI가 하나만 발견되었습니다. Eclipse 통합은 작동하지만 공식 릴리스는 아니며 공식 업데이트 사이트가 없습니다 (트렁크 http://www.jgit.org/updates 에서 주기적으로 빌드되는 일부 외부 업데이트 사이트 만 해당 ) Git을 사용하는 가장 선호되는 방법 명령 행입니다.
SourceGear의 Eric Sink 는 분산 및 비 분산 버전 제어 시스템의 차이점에 대한 일련의 기사를 썼습니다. 그는 가장 인기있는 버전 관리 시스템의 장단점을 비교합니다. 매우 흥미로운 독서.
그의 블로그 www.ericsink.com 에서 기사를 찾을 수 있습니다 .
좋은 Git GUI를 찾는 사람들 에게는 Syntevo SmartGit 이 좋은 솔루션 일 수 있습니다. 독점적이지만 비상업적 인 용도로는 무료이며 Windows / Mac / Linux에서 실행되며 일종의 git-svn 브리지를 사용하여 SVN을 지원한다고 생각합니다.
http://subversion.wandisco.com/component/content/article/1/40.html
개발자들 사이에서 SVN Vs라고 말하는 것이 안전하다고 생각합니다. Git 논쟁은 현재 어느 날 더 강해졌다. 이것은 2010 년과 그 이후에 Subversion에 관한 웹 세미나에서 제기 된 질문들에서도 제기되었습니다.
Open Source의 이사이자 Subversion Corporation의 회장 인 Hyrum Wright는 다른 분산 버전 제어 시스템 (DVCS)과 함께 Subversion과 Git의 차이점에 대해 이야기합니다.
또한 WC-NG (Working Copy Next Generation)와 같이 곧 출시 될 Subversion의 변경 사항에 대해서도 설명합니다.이 버전에서는 많은 Git 사용자가 Subversion으로 다시 전환 할 것으로 생각합니다.
그의 동영상을보고이 블로그에 댓글을 달거나 포럼에 게시하여 의견을 보내주세요. 등록은 간단하며 시간이 조금 걸립니다!
Windows의 Git은 현재 잘 지원됩니다.
GitExtensions = http://code.google.com/p/gitextensions/를 확인하십시오 .
더 나은 Windows Git 경험을위한 설명서.
나는 최근에 Git 랜드에 거주하고 있으며 개인 프로젝트를 좋아하지만, 직원의 요구에 대한 생각이 바뀌지 않으면 서 Subversion에서 작업 프로젝트를 프로젝트로 전환 할 수는 없었습니다. 또한 우리가 사내에서 운영하는 가장 큰 프로젝트는 svn : externals 에 크게 의존합니다 .
첫째, 동시 버전 제어는 해결하기 쉬운 문제인 것 같습니다. 전혀 아닙니다. 어쨌든...
SVN은 직관적이지 않습니다. 힘내가 더 나빠. [sarcastic-speculation] 동시 버전 제어와 같은 어려운 문제와 같은 개발자가 좋은 UI를 만드는 데 큰 관심이 없기 때문일 수 있습니다. [/ 비꼬는 투기]
SVN 지지자들은 분산 버전 제어 시스템이 필요하지 않다고 생각합니다. 나도 그렇게 생각했다. 그러나 이제 Git을 독점적으로 사용하기 때문에 저는 신자입니다. 이제 버전 관리가 프로젝트를 위해 일하는 대신 나와 팀 / 프로젝트에 효과적입니다. 지점이 필요할 때 지점입니다. 때로는 서버에 해당 분기가있는 분기이며 때로는 그렇지 않습니다. 내가 연구해야 할 다른 모든 장점은 말할 것도없고 (일부 최신 버전 제어 시스템 인 UI의 불충분하고 터무니없는 부족 덕분에).
Subversion이 유용성 및 간단한 워크 플로로 인해 Git (최소한 작업중인 프로젝트)보다 낫다고 생각하는 이유는 다음과 같습니다.
http://www.databasesandlife.com/why-subversion-is-better-than-git/