종류 - svn이란




Git이 Subversion보다 나은 이유는 무엇입니까? (20)

나는 몇 년 동안 Subversion 을 사용해 왔으며 SourceSafe 를 사용한 후에는 Subversion 을 좋아합니다. TortoiseSVN 과 결합하여 어떻게 그것이 더 나을 수 있는지 상상할 수 없습니다.

그러나 Subversion에 문제가 있으며 Git 과 같은 새로운 유형의 분산 버전 제어 시스템으로 옮겨야한다고 주장하는 개발자가 점점 늘어나고 있습니다.

Git은 Subversion을 어떻게 개선합니까?


" Git이 X보다 나은 이유 "는 Git과 다른 SCM의 다양한 장단점을 설명합니다.

간단히:

  • Git 은 파일이 아닌 컨텐츠를 추적
  • 지점은 가벼우 며 병합이 쉽고 정말 쉽다는 것을 의미합니다.
  • 기본적으로 모든 저장소는 지점입니다. 내 생각에 Subversion보다 동시에 공동 작업을 개발하는 것이 훨씬 쉽습니다. 또한 오프라인 개발이 가능합니다.
  • 위에 링크 된 웹 사이트 에서 볼 수 있듯이 Git에는 많은 워크 플로우가 있습니다. Subversion 스타일 워크 플로는 쉽게 모방됩니다.
  • Git 리포지토리는 Subversion 리포지토리보다 파일 크기 가 훨씬 작습니다 . 수십 개의 ".svn"리포지토리와 달리 ".git"디렉토리는 하나뿐입니다 (Subversion 1.7 이상 에서는 Git과 같은 단일 디렉토리를 사용 합니다).
  • 준비 영역은 훌륭합니다. 커밋 할 변경 사항을보고 부분 변경 사항을 커밋하고 다양한 다른 작업을 수행 할 수 있습니다.
  • 스 태싱 은 "혼돈적인"개발을 수행 할 때 또는 다른 지점에서 다른 작업을하고있는 동안 단순히 버그를 수정하려고 할 때 매우 중요합니다.
  • 패치 세트를 준비하고 실수를 수정하는 데 도움이되는 history다시 작성할 수 있습니다 (커밋을 게시 하기 전에 )
  • … 그리고 훨씬 더.

몇 가지 단점이 있습니다.

  • 아직 좋은 GUI는 많지 않습니다. 새로운 기능이며 Subversion은 훨씬 더 오랫동안 사용되어 왔으므로 개발에 인터페이스가 거의 없기 때문에 자연 스럽습니다. Mac 용 code.google.com/p/tortoisegitGitHub가 좋은 예입니다.
  • 현재 리포지토리의 일부 체크 아웃 / 복제는 불가능합니다 (개발 중임을 읽었습니다). 그러나 하위 모듈 지원이 있습니다. Git 1.7+는 스파 스 체크 아웃을 지원합니다 .
  • 비록 이것이 사실이 아니더라도 (약 1 년 전) 배우기가 더 어려울 수 있습니다. Git은 최근 인터페이스를 개선했으며 사용자 친화적입니다.

가장 간단한 사용법에서 Subversion과 Git은 거의 동일합니다. 다음과 같이 큰 차이가 없습니다.

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Git이 실제로 빛나는 곳은 다른 사람들과 분기하고 협력하는 것입니다.


DVCS에 대해 내가 좋아하는 요점은 다음과 같습니다.

  1. 깨진 것들을 저지를 수 있습니다. 게시 할 때까지 다른 사람이 볼 수 없기 때문에 중요하지 않습니다. 게시 시간은 커밋 시간과 다릅니다.
  2. 이 때문에 더 자주 커밋 할 수 있습니다.
  3. 완전한 기능성을 병합 할 수 있습니다. 이 기능에는 자체 분기가 있습니다. 이 브랜치의 모든 커밋은이 기능과 관련이 있습니다. CVCS로 DVCS를 기본값으로 사용할 수 있습니다.
  4. 당신은 당신의 역사를 검색 할 수 있습니다 (기능이 변경되었을 때 찾기)
  5. 누군가 주 저장소를 망쳐 놓으면 풀을 실행 취소 할 수 있으며 오류를 수정할 필요가 없습니다. 병합을 지우십시오.
  6. 어떤 디렉토리에서나 소스 컨트롤이 필요할 때 : git init. 그리고 당신은 커밋, 변경 취소 등을 할 수 있습니다 ...
  7. 빠르다 (Windows에서도)

비교적 큰 프로젝트의 주된 이유는 포인트 3에 의해 생성 된 커뮤니케이션이 향상 되었기 때문입니다. 다른 것들은 좋은 보너스입니다.


Git을 사용하면 모든 사람이 자신의 저장소를 가지고 있기 때문에 실제로 오프라인으로 무엇이든 할 수 있습니다.

브랜치를 만들고 브랜치를 병합하는 것은 정말 쉽습니다.

프로젝트에 대한 커밋 권한이 없더라도 온라인으로 자체 저장소를 보유하고 패치에 대한 "푸시 요청"을 게시 할 수 있습니다. 패치를 좋아하는 모든 사람은 공식 관리자를 포함하여 패치를 프로젝트에 가져올 수 있습니다.

프로젝트를 포크하고 수정하고 HEAD 브랜치의 버그 수정을 계속 병합하는 것은 쉽지 않습니다.

Git은 Linux 커널 개발자를 위해 일합니다. 그것은 정말 빠르며 (수행해야 함) 수천 명의 기여자에게 확장됨을 의미합니다. Git은 더 적은 공간을 사용합니다 (Mozilla 리포지토리의 경우 최대 30 배 더 적은 공간).

Git은 매우 유연하고 매우 TIMTOWTDI입니다 (하나 이상의 방법이 있습니다). 원하는 워크 플로를 사용할 수 있으며 Git에서 지원합니다.

마지막으로 Git 리포지토리를 호스팅하기에 좋은 사이트 인 GitHubGitHub .

힘내의 단점 :

  • Git에는 더 많은 개념과 더 많은 명령이 있기 때문에 배우기가 훨씬 어렵습니다.
  • 개정판에는 하위 버전과 같은 버전 번호가 없습니다.
  • 많은 Git 명령은 암호화되어 있으며 오류 메시지는 사용자에게 매우 친숙하지 않습니다.
  • 좋은 GUI가 부족합니다 (예 : 위대한 TortoiseSVN )


Subversion은 괜찮다고 생각합니다. 병합을 시작하거나 복잡한 작업을 수행 할 때까지 또는 Subversion은 복잡한 작업을 수행합니다. 특정 파일을 엉망으로 만든 분기를 찾기위한 쿼리 수행, 실제로 변경이 발생한 위치, 복사 및 붙여 넣기 감지 등) ...

GIT의 주요 이점 은 오프라인 작업이라고 말하면서 당첨 된 답변에 동의하지 않습니다. 확실히 유용하지만 사용 사례에 대한 추가 기능과 같습니다. SVK는 오프라인에서도 작동 할 수 있지만 여전히 학습 시간에 투자해야 할 질문은 없습니다.)

그것은 매우 강력하고 빠르며 개념에 익숙해지면 매우 유용합니다 (그렇습니다, 그런 의미에서 : 사용자 친화적).

병합 이야기에 대한 자세한 내용은 다음을 참조하십시오 : git-svn (또는 비슷한) * 그냥 *를 사용하여 svn 병합에 도움이됩니까?


Subversion은 여전히 ​​훨씬 더 많이 사용되는 버전 관리 시스템이므로 도구 지원이 향상되었습니다. 거의 모든 IDE 용 성숙한 SVN 플러그인을 찾을 수 있으며 TurtoiseSVN과 같은 훌륭한 탐색기 확장이 있습니다. 그 외에는 Michael 과 동의해야합니다 : Git은 Subversion보다 낫거나 나쁘지 않습니다.


글쎄, 배포되었습니다. 벤치 마크는 상당히 빠르며 (분산 된 특성, diff 및 log와 같은 작업은 모두 로컬이므로 물론이 경우 엄청나게 빠릅니다) 작업 폴더는 더 작습니다 (여전히 마음이 아파요).

Subversion 또는 다른 클라이언트 / 서버 개정 관리 시스템에서 작업 할 때는 개정판을 체크 아웃 하여 시스템에서 작업 사본을 작성해야합니다. 리포지토리의 모양에 대한 스냅 샷을 나타냅니다. 업데이트를 통해 작업 복사본을 업데이트하고 커밋을 통해 리포지토리를 업데이트합니다.

분산 버전 제어를 사용하면 스냅 샷이 아니라 전체 코드베이스가 있습니다. 3 개월 된 버전으로 diff를 원하십니까? 문제 없습니다. 3 개월 이전 버전은 여전히 ​​컴퓨터에 있습니다. 이것은 일이 더 빠르다는 것을 의미 할뿐 아니라 중앙 서버와의 연결이 끊긴 경우에도 이전에 사용하던 많은 작업을 수행 할 수 있습니다. 다시 말해, 주어진 개정의 스냅 샷이 아니라 전체 코드베이스가 있습니다.

Git이 하드 드라이브에서 많은 공간을 차지할 것이라고 생각하지만, 내가 본 몇 가지 벤치 마크에서 실제로는 더 적은 시간이 걸립니다. 방법을 묻지 마십시오. 내 말은, 그것은 Linus에 의해 지어졌으며, 내가 추측하는 파일 시스템에 대해 한두 가지를 알고 있습니다.


다른 답변은 Git의 핵심 기능을 설명하는 데 도움이되었습니다. 그러나 Git이 더 잘 동작하고 내 인생을 더 깨끗하게 유지하는 데 도움이되는 작은 방법이 많이 있습니다. 다음은 몇 가지 작은 것입니다.

  1. 힘내 '깨끗한'명령이 있습니다. SVN은 디스크에 추가 파일을 얼마나 자주 덤프 할지를 고려할 때이 명령이 절실히 필요합니다.
  2. 힘내에는 'bisect'명령이 있습니다. 좋네요
  3. SVN은 모든 단일 폴더에 .svn 디렉토리를 만듭니다 (Git은 하나의 .git 디렉토리 만 만듭니다). 이 .svn 디렉토리를 무시하려면 모든 스크립트와 grep을 작성해야합니다. 파일을 제대로 복사하려면 전체 명령 ( "svn export")이 필요합니다.
  4. SVN에서 각 파일 및 폴더는 다른 버전 또는 분기에서 제공 될 수 있습니다. 처음에는 이러한 자유를 누리는 것이 좋습니다. 그러나 이것이 실제로 의미하는 것은 로컬 체크 아웃이 완전히 망칠 수있는 백만 가지 방법이 있다는 것입니다. (예를 들어, "svn switch"가 중간에 실패하거나 명령을 잘못 입력 한 경우). 최악의 부분은 파일의 일부가 다른 곳에서 오는 경우가 있고 일부는 다른 곳에서 오는 경우 "svn status"는 모든 것이 정상임을 나타냅니다. 각기 다른 파일 / 디렉토리에 대해 "svn info"를 수행하여 이상한 점을 발견해야합니다. "git status"가 일이 정상이라고 말하면, 일이 실제로 정상임을 믿을 수 있습니다.
  5. 무언가를 이동하거나 삭제할 때마다 SVN에 알려야합니다. 힘내 그냥 알아낼 것입니다.
  6. Git에서 의미를 무시하는 것이 더 쉽습니다. 패턴을 무시하면 (예 : * .pyc) 모든 서브 디렉토리에서 무시됩니다. (단 하나의 디렉토리에 대해서만 무언가를 무시하고 싶다면 가능합니다). SVN을 사용하면 모든 하위 디렉토리에서 패턴을 무시하는 쉬운 방법이없는 것 같습니다.
  7. 파일 무시와 관련된 다른 항목입니다. Git을 사용하면 "private"설정을 무시할 수 있습니다 (.git / info / exclude 파일 사용). 다른 사람에게는 영향을 미치지 않습니다.

실제로 Git은 중소 규모의 팀에서 커뮤니케이션 개발자와 개발자 간의 커뮤니케이션에 도움이되기 때문에 좋아합니다. 분산 버전 제어 시스템 인 푸시 / 풀 시스템을 통해 개발자는 단일 프로젝트에서 작업하는 대규모 개발자 풀을 관리하는 데 도움이되는 소스 코드 에코 시스템을 만들 수 있습니다.

예를 들어 5 명의 개발자를 신뢰하고 자신의 저장소에서 코드 만 가져옵니다. 각 개발자는 코드를 가져 오는 자체 신뢰 네트워크를 가지고 있습니다. 따라서 개발은 코드 책임이 개발 커뮤니티에서 공유되는 개발자의 신뢰 구조를 기반으로합니다.

물론 여기에 다른 답변에서 언급 된 다른 이점이 있습니다.


여기에 모든 대답은 프로그래머 중심의 예상대로이지만 회사에서 소스 코드 외부에서 개정 제어를 사용하면 어떻게됩니까? 버전 제어의 혜택을받는 소스 코드가 아닌 다른 문서가 많이 있으며 다른 CMS가 아닌 코드에 가깝게 살아야합니다. 대부분의 프로그래머는 독립적으로 일하지 않습니다. 우리는 팀의 일원으로 회사를 위해 일합니다.

이를 염두에두고 클라이언트 툴링 및 교육에서 Subversion과 git 간의 사용 편의성을 비교하십시오. 분산 개정 제어 시스템이 프로그래머가 아닌 사람에게 더 쉽게 사용하거나 설명 할 수있는 시나리오를 볼 수 없습니다. 나는 git을 평가할 수 있고 실제로 프로그래머가 아닌 버전 관리가 필요한 사람들이 그것을 받아 들일 희망을 가지고 있기 때문에 틀린 것으로 입증되고 싶습니다.

그럼에도 불구하고 경영진이 왜 중앙 집중식에서 분산 개정 제어 시스템으로 전환해야하는지 묻는다면 필요하지 않기 때문에 정직한 답변을 제공하기가 어려울 것입니다.

면책 조항 : 나는 약 v0.29 초반에 Subversion에 관심을 갖게되었으므로 분명히 편견이 있지만 그 이후로 일한 회사는 그 사용을 장려하고 지원했기 때문에 열정으로 이익을 얻습니다. 나는 이것이 대부분의 소프트웨어 회사에서 일어나는 방식이라고 생각합니다. 너무 많은 프로그래머가 git bandwagon에 뛰어 들면서 소스 코드 외부에서 버전 제어를 사용하는 이점을 얼마나 많은 회사가 놓칠 지 궁금합니다. 팀마다 별도의 시스템이 있더라도 유지 관리, 하드웨어 및 교육 요구 사항이 증가하는 동안 (통합) 문제 추적 통합과 같은 몇 가지 이점이 빠져 있습니다.


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

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

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

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

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

중앙 서버와 지속적으로 통신 할 필요가 없기 때문에 거의 모든 명령이 1 초 이내에 실행됩니다 (물론 git push / pull / fetch는 SSH 연결을 초기화해야하기 때문에 속도가 느려집니다). 분기가 훨씬 쉽습니다 (하나의 간단한 명령은 분기하고 하나는 병합하는 간단한 명령입니다)


힘내 또한 분기 및 병합을 정말 쉽게합니다. Subversion 1.5는 병합 추적을 추가했지만 Git이 여전히 좋습니다. 힘내 분기와 매우 빠르고 저렴합니다. 각각의 새로운 기능에 대한 브랜치를 만드는 것이 더 가능합니다. Oh 및 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에서는)이 빛납니다.


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으로 다시 전환 할 것으로 생각합니다.

그의 동영상을보고이 블로그에 댓글을 달거나 포럼에 게시하여 의견을 보내주세요. 등록은 간단하며 시간이 조금 걸립니다!


SourceGear의 Eric Sink 는 분산 및 비 분산 버전 제어 시스템의 차이점에 대한 일련의 기사를 썼습니다. 그는 가장 인기있는 버전 관리 시스템의 장단점을 비교합니다. 매우 흥미로운 독서.
그의 블로그 www.ericsink.com 에서 기사를 찾을 수 있습니다 .




나는 최근에 Git 랜드에 거주하고 있으며 개인 프로젝트를 좋아하지만, 직원의 요구에 대한 생각이 바뀌지 않으면 서 Subversion에서 작업 프로젝트를 프로젝트로 전환 할 수는 없었습니다. 또한 우리가 사내에서 실행하는 가장 큰 프로젝트는 svn:externals 에 크게 의존합니다. svn:externals 는 지금까지 본 것에서 Git에서 완벽하고 원활하게 작동하지 않습니다.


좋은 Git GUI를 찾는 사람들 에게는 Syntevo SmartGit 이 좋은 솔루션 일 수 있습니다. 독점적이지만 비상업적 인 용도로는 무료이며 Windows / Mac / Linux에서 실행되며 일종의 git-svn 브리지를 사용하여 SVN을 지원한다고 생각합니다.





git