SVN 또는 Git을 사용해야합니까? [닫은]

새로운 분산 프로젝트를 시작하고 있습니다. SVN 또는 Git을 사용해야합니까? 그 이유는 무엇입니까?

SVN은 하나의 저장소이고 많은 클라이언트입니다. 힘내는 클라이언트 리포지토리가 많은 리포지토리이며, 각각 사용자가 있습니다. 사람들이 외부 서버로 작업을 푸시하지 않고도 로컬에서 자신의 편집 내용을 추적 할 수있는 지점으로 분산되어 있습니다.

SVN은 Git이 자신의 Git 리포지토리를 가진 각 사용자를 기반으로하는 더 중심적인 위치에 설계되었으며 이러한 리포지토리 변경 사항은 다시 중앙 위치로 변경됩니다. 이런 이유로 Git은 개인에게 더 나은 로컬 버전 관리 기능을 제공합니다.

한편 , TortoiseGit , GitExtensions 중에서 선택할 수 있습니다 (그리고 자신의 클라이언트 인 github ( Windows 용 GitHub)에서 "중앙"git-repository를 호스팅하는 경우 ).

SVN에서 벗어나기를 원한다면 Bazaar 를 약간 평가 해 볼 수 있습니다 . 이 분산 요소가있는 차세대 버전 제어 시스템 중 하나입니다. git과 같이 POSIX에 의존하지 않으므로 기본 Windows 빌드 가 있으며 강력한 오픈 소스 브랜드가 있습니다.

그러나 아직 이러한 종류의 기능이 필요하지 않을 수도 있습니다. 한 번 봐 가지고 분산 VCSes의 특징, 장점과 단점 . SVN 오퍼보다 더 필요한 경우 하나를 고려하십시오. 그렇지 않은 경우 SVN의 (현재) 우수한 데스크탑 통합을 고수 할 수 있습니다.

나는 "Windows에서는 좋지 않다"라는이 개념을 결코 이해하지 못했다. 나는 Windows에서만 독점적으로 개발했으며 git에 아무런 문제가 없었습니다.

나는 git over subversion을 추천 할 것이다; 그것은 단순히 훨씬 더 다재다능하고 subversion이 결코 할 수 없었던 방식으로 "오프라인 개발"을 허용합니다. 상상할 수있는 거의 모든 플랫폼에서 사용할 수 있으며 아마도 사용할 것보다 많은 기능을 가지고 있습니다.

다음은 Git vs. SVN (2009 년 9 월)에 대해 삭제 된 이후 중복 된 질문 에 대한 답변의 사본입니다 .

보다 나은? 일반적인 링크 WhyGitIsBetterThanX 외에는 서로 다릅니다.

하나는 지점에 대한 저렴한 사본을 기반으로하는 중앙 VCS이고 태그는 다른 그래프 (Git)는 개정 그래프를 기반으로하는 분산 VCS입니다. VCS의 핵심 개념도 참조하십시오 .

그 첫 부분은 두 프로그램 (SVN과 Git)의 기본 목적은 동일하지만 그것들이 상당히 다르게 구현되었다고 주장하는 잘못된 정보 주석을 생성했습니다. SVN과 Git
의 근본적인 차이점 을 명확히하기 위해 다음 과 같이 바꾸어 보겠습니다.

• SVN은 개정 제어 의 세 번째 구현입니다 . RCS, CVS 및 SVN 은 버전이 지정된 데이터의 디렉토리를 관리합니다. SVN은 VCS 기능 (라벨링 및 병합)을 제공하지만 태그는 디렉토리 사본 일 뿐이며 (태그 디렉토리의 아무 것도 터치하지 않을 경우를 제외하고 분기와 유사) 병합은 여전히 ​​복잡하며 메타를 기반으로합니다. -이미 병합 된 것을 기억하기 위해 데이터가 추가되었습니다.

• Git은 파일 컨텐츠 관리 (파일 병합 도구)로, 커밋 의 DAG ( Directed Acyclic Graph )를 기반으로 진정한 버전 제어 시스템으로 발전했습니다. ) 및 where 태그는 실제 메타 데이터입니다.

당신이 같은 것을 달성하고 같은 문제를 해결할 수 있기 때문에 "기본적으로"다르지 않다고 말하는 것은 ... 많은 수준에서 명백한 거짓입니다.

• 복잡한 병합이 많은 경우 SVN을 사용하면 병합 시간이 길어지고 오류가 발생하기 쉽습니다. 많은 브랜치를 생성 해야하는 경우 SVN보다 Git을 사용하여 훨씬 쉽게 더 쉽게 브랜치를 관리하고 병합해야합니다. 특히 많은 수의 파일이 관련된 경우 (속도가 중요합니다)
• 진행중인 작업에 대해 부분적으로 병합하는 경우 Git 준비 영역 (인덱스)을 활용하여 필요한 것만 커밋하고 나머지는 숨기고 다른 지점으로 이동합니다.
• 오프라인 개발이 필요한 경우 ... Git을 사용하면 다른 리포지토리에서 수행하려는 워크 플로에 관계없이 항상 로컬 리포지토리를 통해 "온라인"상태가됩니다.

여전히 오래된 (삭제 된) 답변에 대한 의견은 다음과 같이 주장했습니다.

VonC : 구현의 근본적인 차이 (차이는 매우 근본적이며 우리 모두는 이에 동의합니다)와 목적의 차이를 혼동하고 있습니다.
그것들은 모두 같은 목적으로 사용되는 도구입니다. 이전에 SVN을 사용했던 많은 팀들이 Git을 위해 그것을 성공적으로 버릴 수 있었던 이유입니다.
그들이 같은 문제를 해결하지 못했다면이 대체 가능성 은 존재하지 않을 것입니다.

내가 대답 한 :

"substitutability"... 재미있는 용어 ( 컴퓨터 프로그래밍에 사용됨 ).
물론 Git은 SVN의 하위 유형이 아닙니다.

둘 다 동일한 기술 기능 (태그, 브랜치, 병합)을 달성 할 수 있지만 Git은 방해가되지 않으며 도구 자체에 대해 생각하지 않고도 파일 내용에 집중할 수 있습니다 .

당신은 확실히 (항상) 단지 (전술에 대한 참조이다 "(작업이 수행 ... 정확성) 그 프로그램의 바람직한 특성 중 하나를 변경하지 않고"힘내으로 SVN을 대체 할 수 대체 가능성 정의 ) :

• 하나는 확장 버전 도구이고 다른 하나는 실제 버전 제어 시스템입니다.
• 하나는 단순한 병합 워크 플로와 (너무 많지 않은) 병렬 버전을 갖춘 중소 규모 모 놀리 식 프로젝트에 적합합니다. SVN은 이러한 목적으로 충분하며 모든 Git 기능이 필요하지 않을 수 있습니다.
• 다른 하나 는 복잡한 병합 워크 플로의 여러 분기, 분기의 병렬 버전, 병합 병합 등에서 여러 개의 파일을 사용 하여 여러 구성 요소 (구성 요소 당 하나의 리포지토리)를 기반으로하는 중대형 프로젝트를 허용 합니다. SVN으로 할 수는 있지만 Git을 사용하면 훨씬 좋습니다.
  SVN은 병합 워크 플로를 사용하여 어떤 크기의 프로젝트도 관리 할 수 ​​없습니다. 힘내.

다시 말하지만, 그들의 본질은 근본적으로 다릅니다 (이는 다른 구현으로 이어지지 만 요점이 아닙니다).
하나는 디렉토리와 파일로 개정 관리를보고 다른 하나는 파일의 내용 만 볼 수 있습니다 (빈 디렉토리는 Git에 등록되지 않습니다!).

일반적인 최종 목표는 동일 할 수 있지만 동일한 방식으로 사용할 수 없으며 동일한 범위의 문제를 해결할 수 없습니다 (범위 또는 복잡성).

거의 언급되지 않는 SVN의 2 가지 주요 장점 :

1. 큰 파일 지원. 코드 외에도 SVN을 사용하여 홈 디렉토리를 관리합니다. SVN은 TrueCrypt 파일에서 질식하지 않는 유일한 VCS (분산 여부)입니다 (500MB 이상 파일을 효과적으로 처리하는 다른 VCS가있는 경우 수정하십시오). diff 비교가 스트리밍되기 때문입니다 (매우 중요한 포인트입니다). Rsync는 양방향이 아니므로 허용되지 않습니다.

2. 부분 저장소 (subdir) 체크 아웃 / 체크인. Mercurial과 bzr은 이것을 지원하지 않으며 git의 지원은 제한적입니다. 이것은 팀 환경에서는 좋지 않지만 내 홈 디렉토리에서 다른 컴퓨터의 무언가를 확인하고 싶다면 귀중합니다.

단지 내 경험.

더 많은 연구를하고이 링크를 검토 한 후 : https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(아래 일부 추출물) :

• 엄청나게 빠릅니다. 내가 사용한 다른 SCM 은이를 따라갈 수 없었으며 Subversion, Perforce, darcs, BitKeeper, ClearCase 및 CVS를 포함하여 많이 사용했습니다.
• 완전히 배포되었습니다. 저장소 소유자는 내가 일하는 방식을 지시 할 수 없습니다. 랩톱에서 연결을 끊은 상태에서 분기를 만들고 변경 사항을 커밋 한 다음 나중에 다른 리포지토리와 동기화 할 수 있습니다.
• 많은 미디어에서 동기화가 발생할 수 있습니다. WebDAV를 통해 HTTP를 통해, FTP를 통해 또는 메시지 수신자가 적용 할 패치가 포함 된 이메일을 전송하여 SSH 채널. 중앙 저장소는 필요하지 않지만 사용할 수 있습니다.
• 지점은 Subversion보다 훨씬 저렴합니다. 브랜치를 만드는 것은 41 바이트 파일을 디스크에 쓰는 것만 큼 간단합니다. 브랜치를 삭제하는 것은 해당 파일을 삭제하는 것만 큼 간단합니다.
• Subversion 브랜치와 달리 전체 기록이 적용됩니다. 이상한 사본을 수행하지 않고 사본을 살펴볼 필요가 없습니다. Subversion을 사용할 때 나는 브랜치를 만들기 전에 발생한 브랜치에서 파일의 기록을 보는 것이 항상 어색하다는 것을 알았습니다. from #git : spearce : 페이지에서 SVN에 대해 한 가지 이해하지 못합니다. 나는 SVN 지점을 만들었고 기록을 탐색하면 지점의 전체 기록이 파일로 표시됩니다.
• Git에서는 브랜치 병합이 더 간단하고 자동적입니다. Subversion에서는 올바른 병합 명령을 생성 할 수 있도록 마지막으로 병합 한 버전을 기억해야합니다. 힘내이 작업을 자동으로 수행하고 항상 올바르게 수행합니다. 즉, 두 개의 브랜치를 병합 할 때 실수 할 가능성이 줄어 듭니다.
• 지점 병합은 리포지토리의 올바른 기록의 일부로 기록됩니다. 두 개의 브랜치를 병합하거나 브랜치를 트렁크에서 다시 병합하는 경우 해당 병합 작업은 언제, 언제 수행했는지와 함께 repostory 기록의 일부로 기록됩니다. 병합이 로그에있을 때 누가 병합을 수행했는지 논쟁하기가 어렵습니다.
• 저장소 작성은 간단한 작업입니다. mkdir foo; cd foo; git init 그게 다야. 요즘에는 모든 것을 위해 Git 저장소를 만듭니다. 클래스 당 하나의 저장소를 사용하는 경향이 있습니다. 강의 노트, 과제물 및 LaTeX 답변 만 저장하기 때문에 이러한 저장소의 대부분은 디스크 1MB 미만입니다.
• 저장소의 내부 파일 형식은 매우 간단합니다. 이것은 수리가 매우 쉽지만 손상되기가 매우 간단하기 때문에 더 좋습니다. 나는 누군가 Git 저장소가 손상되었다고 생각하지 않는다. fsfs로 Subversion이 손상되는 것을 보았습니다. 그리고 Berkley DB가 Subversion의 bdb 백엔드에 내 코드를 신뢰하기에 너무 많이 손상되는 것을 보았습니다.
• Git의 파일 형식은 매우 간단한 형식 임에도 불구하고 데이터 압축에 매우 적합합니다. Mozilla 프로젝트의 CVS 저장소는 약 3GB입니다. Subversion의 fsfs 형식은 약 12GB입니다. Git에서는 약 300MB입니다.

이 모든 것을 읽은 후에는 Git이 갈 길이라고 확신합니다 (약간의 학습 곡선이 있음에도 불구하고). Windows 플랫폼에서도 Git과 SVN을 사용했습니다.

위의 내용을 읽은 후 다른 사람들의 의견을 듣고 싶습니다.

Subversion 저장소를 설정하겠습니다. 이 방법으로 개별 개발자는 Subversion 클라이언트를 사용할지 Git 클라이언트를 사용할지 () 선택할 수 있습니다 git-svn. 사용 git-svn은 완전한 Git 솔루션의 모든 이점을 제공하지는 않지만 개별 개발자가 자신의 워크 플로를 크게 제어 할 수 있습니다.

나는 Git이 Unix와 Mac OS X 에서처럼 Windows에서 잘 작동하기 전에 비교적 짧은 시간이 될 것이라고 믿습니다.

Subversion에는 탐색기 통합을위한 TortoiseSVN 및 Visual Studio 통합을위한 AnkhSVN과 같은 Windows 용 도구가 있습니다.

재미있는 점은 Subversion Repos에서 프로젝트를 호스팅하지만 Git Clone 명령을 통해 프로젝트에 액세스한다는 것입니다.

Google 코드 프로젝트에서 Git으로 개발을 읽으십시오.

Google 코드는 기본적으로 Subversion을 사용하지만 개발 중에 Git을 쉽게 사용할 수 있습니다. "git svn"을 검색하면이 방법이 널리 퍼져 있음을 알 수 있으며 실험 해 보는 것도 좋습니다.

Svn 리포지토리에서 Git을 사용하면 다음과 같은 이점이 있습니다.

1. 여러 컴퓨터에 분산 되어 작업을 수행 할 수 있습니다.
2. 다른 사람들이 체크 아웃 할 수있는 중앙 backup/public svn 저장소가 있습니다.
3. 그리고 그들은 Git을 자유롭게 사용할 수 있습니다.

실제로 귀하의 질문에 대답하지는 않지만 Distributed Revision Control 의 이점을 원한다면 (사운드처럼 들리며) Windows를 사용하고 있습니다. Mercurial이 훨씬 나은 Windows 지원을 제공하는 것보다 Git 보다 Mercurial 을 사용 하는 것이 좋습니다. Mercurial에는 Mac 포트도 있습니다.

팀이 이미 cvs 또는 svn과 같은 버전 및 소스 제어 소프트웨어에 익숙하다면 간단하고 작은 프로젝트 (예 : 주장하는 것처럼)에 대해 SVN을 따르는 것이 좋습니다. 나는 svn에 정말 익숙하지만 현재 전자 상거래 프로젝트에서 django를 사용하고 있는데 git에 대해 작업하기로 결정했습니다 (나는 svn 모드에서 git을 사용하고 있습니다. 적어도 하나의 다른 개발자와 협력하기 위해). 다른 개발자는 SVN에 익숙하고 다른 사람들의 경험은 다를 수 있지만 우리 모두는이 작은 프로젝트에 git을 수용하는 데 정말 나쁜 시간을 보내고 있습니다. (우리는 하드 코어 리눅스 사용자 모두 중요하다.)

물론 마일리지는 다를 수 있습니다.

확실히 svn, Windows는 세계 최고 수준의 시민이기 때문에 git( 자세한 내용 은 http://en.wikipedia.org/wiki/Git_(software)#Portability 를 참조하십시오).

업데이트 : 끊어진 링크에 대해 죄송하지만 괄호가 포함 된 URI로 작업하도록 SO를 포기하려고했습니다. [링크가 수정되었습니다. -ed]

요점은 Git은 분산 VCS이고 Subversion은 중앙 집중식입니다. 분산 VCS는 이해하기가 조금 더 어렵지만 많은 장점이 있습니다. 이 장점이 필요하지 않으면 Subversion이 더 나은 선택 일 수 있습니다.

또 다른 질문은 도구 지원입니다. 사용하려는 도구가 어떤 VCS를 더 잘 지원합니까?

편집 : 3 년 전 나는 이런 식으로 대답했다.

그리고 Git은 현재 Cygwin 또는 MSYS를 통해서만 Windows에서 작동합니다 . Subversion은 Windows를 처음부터 지원했습니다. Windows 용 git-solutions가 효과가있을 수 있으므로 Git 개발자 대부분이 Linux에서 작업하고 처음부터 이식성이 없었기 때문에 문제가있을 수 있습니다. 현재 Windows에서 개발하기 위해 Subversion을 선호합니다. 몇 년 안에 이것은 관련이 없을 수 있습니다.

이제 세상은 조금 바뀌 었습니다. Git은 이제 Windows에서 잘 구현되었습니다. 더 이상이 시스템을 사용하지 않기 때문에 Windows에서 철저하게 테스트하지는 않았지만 모든 주요 VCS (SVN, Git, Mercurial, Bazaar)가 이제 적절한 Windows 구현을 가지고 있다고 확신합니다. SVN의 이점은 사라졌습니다. 다른 지점 (중앙 집중식과 분산 식 및 도구 지원 확인)은 계속 유효합니다.

SVN이 더 널리 퍼지고 더 잘 알려져 있기 때문에 SVN을 선택합니다.

리눅스 사용자에게는 Git이 더 좋을 것 같습니다.

Git은 아직 Windows에서 기본적으로 지원되지 않습니다. Posix 시스템에 최적화되어 있습니다. 그러나 Cygwin 또는 MinGW를 실행하면 Git을 성공적으로 실행할 수 있습니다.

요즘에는 SVN보다 Git을 선호하지만 SVN 토지 CVS에서 온 경우 임계 값을 초과하는 데 시간이 걸립니다.

SVN보다 훨씬 강력하기 때문에 Git을 선택했을 것입니다. 저렴한 코드 호스팅 서비스를 이용할 수 있습니다. 백업이나 유지 관리 작업을 수행 할 필요가 없습니다. GitHub 가 가장 확실한 후보입니다.

즉, Visual Studio와 다른 SCM 시스템의 통합에 대해서는 아무것도 모릅니다. SVN과의 통합이 눈에 띄게 더 좋습니다.

나는 SVN을 오랫동안 사용했지만 Git을 사용할 때마다 Git이 훨씬 강력하고 가벼우 며 약간의 학습 곡선이 관여하지만 SVN보다 낫다고 느꼈습니다.

내가 언급 한 것은 각 SVN 프로젝트가 커지면 내 보내지 않는 한 매우 큰 프로젝트가된다는 것입니다. GIT 프로젝트 (Git 데이터와 함께)는 크기가 매우 가볍습니다.

SVN에서는 초보자부터 전문가까지 개발자를 다루었으며 초보자와 중간체는 재사용하기 위해 다른 SVN 프로젝트에서 하나의 폴더를 복사하면 파일 충돌을 일으키는 것으로 보입니다. 반면, Git에서는 폴더를 복사하면 Git이 모든 하위 폴더에 .git 폴더를 도입하지 않기 때문에 작동합니다 (SVN처럼).

오랜 시간 동안 SVN을 많이 처리 한 후에 마침내 공동 작업과 병합 작업이 쉽고 로컬 사본의 변경 사항을 최대한 커밋 할 수 있다는 장점이 있기 때문에 개발자와 저를 Git으로 옮길 생각입니다. SVN (서버의 저장소에서 때때로 변경 사항을 커밋해야 함)과 달리 서버의 지점으로 한 번에 푸시했습니다.

내가 실제로 Git과 함께 가야할지 결정하도록 도와 줄 사람이 있습니까?

이것은 다음과 같습니다.

개발이 선형 적일까요? 그렇다면 Subversion을 사용해야합니다.

반면에 개발이 선형 적이 지 않으면 다른 변경 사항에 대한 분기를 생성 한 다음 해당 변경 사항을 기본 개발 라인 (Git에 마스터 분기라고 함)으로 병합해야합니다. 당신을 위해 더 많이.

Bzr 을 사용해 보셨습니까 ?

그것은 시장에서 다른 것을 좋아하지 않기 때문에 꽤 좋고, 공감 적입니다 (우분투를 만드는 사람들)는 그것을 만들었습니다 ...

질문을 확장하고 Git이 MacOS에서 제대로 작동하는지 물어볼 수 있습니까?

댓글에 대한 답장 : 뉴스를 보내 주셔서 감사합니다. 집에서 Mac으로 설치하겠습니다.

이에 관한 YouTube에 흥미로운 비디오가 있습니다. Linus Torwalds 자신의 것 : Goolge Tech Talk : git의 Linus Torvalds

SVN은 다른 사람들이 지적한 것처럼 Windows에서 좋은 선택처럼 보입니다.

개발자 중 일부가 GIT를 사용하려는 경우 SVIT 저장소가 GIT 저장소에서 다시 생성되는 GIT-SVN을 항상 사용할 수 있습니다. 그런 다음 GIT와 로컬로 작업 한 다음 SVN을 사용하여 변경 사항을 기본 저장소에 공개 할 수 있어야합니다.

DVCS와 함께 가야합니다. 소스 관리의 비약적인 발전과 같습니다. 개인적으로 나는 Monotone을 사용 하고 그 개발 시간은 끝이 없습니다. 우리는 Windows, Linux 및 Mac에 사용하고 있으며 매우 안정적입니다. 나는 각 플랫폼에서 프로젝트의 야간 빌드를하는 buildbot도 가지고 있습니다.

DVCS는 일반적으로 배포되는 동안 사람들이 변경 사항을주고받을 수 있도록 중앙 서버를 만들게됩니다.