Git이 Subversion보다 나은 이유는 무엇입니까?
나는 몇 년 동안 Subversion 을 사용해 왔으며 SourceSafe 를 사용한 후에는 Subversion 을 좋아합니다. TortoiseSVN 과 결합하여 어떻게 그것이 더 나을 수 있는지 상상할 수 없습니다.
그러나 Subversion에 문제가 있으며 Git 과 같은 새로운 유형의 분산 버전 제어 시스템으로 옮겨야한다고 주장하는 개발자가 점점 늘어나고 있습니다 .
Git은 Subversion을 어떻게 개선합니까?
힘내는 Subversion보다 낫지 않습니다. 그러나 더 나쁘지 않습니다. 그것은 다르다.
중요한 차이점은 분산되어 있다는 것입니다. 이동 중에 개발자이고 랩톱에서 개발하고 3 시간 동안 되돌아 갈 수 있도록 소스 제어를 원한다고 상상해보십시오.
Subversion을 사용하면 문제가 있습니다. SVN 리포지토리가 회사에 도달 할 수없는 위치에있을 수 있으며 (현재 인터넷이없는 경우) 커밋 할 수 없습니다. 코드를 복사하려면 문자 그대로 복사 / 붙여 넣기해야합니다.
Git을 사용하면이 문제가 없습니다. 로컬 사본은 리포지토리이며이를 커밋하고 소스 제어의 모든 이점을 얻을 수 있습니다. 기본 리포지토리에 다시 연결되면 커밋 할 수 있습니다.
이것은 처음에는 좋아 보이지만이 접근 방식에 추가 된 복잡성을 염두에 두십시오.
힘내는 "새롭고 반짝이는 멋진"것 같습니다. 그것은 결코 나쁘지 않습니다 (리누스가 결국 리눅스 커널 개발을 위해 그것을 쓴 이유가 있습니다). 그러나 많은 사람들이 "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. 복제, 커밋 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 배 더 적은 공간).
힘내는 매우 유연하고 매우 TIMTOWTDI입니다 (두 가지 방법이 있습니다). 원하는 워크 플로를 사용할 수 있으며 Git에서 지원합니다.
마지막으로 Git 리포지토리를 호스팅하기에 좋은 사이트 인 GitHub 가 있습니다 .
힘내의 단점 :
- Git에는 더 많은 개념과 더 많은 명령이 있기 때문에 배우기가 훨씬 어렵습니다.
- 개정판에는 하위 버전과 같은 버전 번호가 없습니다.
- 많은 Git 명령은 암호화되어 있으며 오류 메시지는 사용자에게 매우 친숙하지 않습니다.
- 좋은 GUI가 부족합니다 (예 : 위대한 TortoiseSVN )
다른 답변은 Git의 핵심 기능을 설명하는 데 도움이되었습니다. 그러나 Git이 더 잘 동작하고 내 인생을 더 깨끗하게 유지하는 데 도움이되는 작은 방법이 많이 있습니다. 다음은 몇 가지 작은 것입니다.
- 힘내 '깨끗한'명령이 있습니다. SVN은 디스크에 여분의 파일을 얼마나 자주 덤프 할지를 고려할 때이 명령이 절실히 필요합니다.
- 힘내에는 'bisect'명령이 있습니다. 좋네요
- SVN creates .svn directories in every single folder (Git only creates one .git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files.
- SVN에서 각 파일 및 폴더는 다른 버전 또는 분기에서 제공 될 수 있습니다. 처음에는이 자유를 누리는 것이 좋습니다. 그러나 이것이 실제로 의미하는 것은 로컬 체크 아웃이 완전히 망칠 수있는 백만 가지 방법이 있다는 것입니다. (예를 들어 "svn switch"가 중간에 실패하거나 명령을 잘못 입력 한 경우). 최악의 부분은 파일의 일부가 한 곳에서오고 일부는 다른 곳에서 오는 경우 "svn status"는 모든 것이 정상임을 나타냅니다. 각기 다른 파일 / 디렉토리에 대해 "svn info"를 수행하여 이상한 점을 발견해야합니다. "git status"가 일이 정상이라고 말하면, 일이 실제로 정상임을 믿을 수 있습니다.
- 무언가를 이동하거나 삭제할 때마다 SVN에 알려야합니다. 힘내 그냥 알아낼 것입니다.
- Git에서 의미를 무시하는 것이 더 쉽습니다. 패턴을 무시하면 (예 : * .pyc) 모든 서브 디렉토리에서 무시됩니다 . (단 하나의 디렉토리에 대해서만 무언가를 무시하고 싶다면 가능합니다). SVN을 사용하면 모든 하위 디렉토리에서 패턴을 무시하는 쉬운 방법이없는 것 같습니다.
- 파일 무시와 관련된 다른 항목입니다. Git을 사용하면 "private"설정을 무시할 수 있습니다 (.git / info / exclude 파일 사용). 다른 사람에게는 영향을 미치지 않습니다.
" Git이 X보다 나은 이유 "는 Git과 다른 SCM의 다양한 장단점을 설명합니다.
간단히:
- Git 은 파일이 아닌 컨텐츠를 추적
- 지점은 가벼우 며 병합이 쉽고 정말 쉽다는 것을 의미 합니다.
- 기본적으로 모든 저장소는 지점입니다. 내 생각에 Subversion보다 동시에 공동 작업을 개발하는 것이 훨씬 쉽습니다. 또한 오프라인 개발이 가능합니다.
- 그것은 워크 플로우를 부과하지 않습니다 에서 볼 때, 위의 링크 된 웹 사이트 , 힘내와 가능한 많은 작업 흐름이있다. Subversion 스타일 워크 플로는 쉽게 모방됩니다.
- Git 리포지토리는 Subversion 리포지토리보다 파일 크기 가 훨씬 작습니다 . 수십 개의 ".svn"리포지토리와 달리 ".git"디렉토리는 하나뿐입니다 (Subversion 1.7 이상 은 Git과 같은 단일 디렉토리를 사용 합니다).
- 스테이징 영역은 당신이 부분적인 변경 내용을 커밋 커밋합니다 변경 사항을 참조 및 기타 다양한 물건을 수행 할 수 있습니다, 굉장합니다.
- 스 태싱 은 "혼돈적인"개발을 수행하거나 다른 지점에서 다른 작업을하고있는 동안 단순히 버그를 수정하려고 할 때 매우 중요합니다.
- 패치 세트를 준비하고 실수를 수정하는 데 도움이되는 history 를 다시 작성할 수 있습니다 ( 커밋을 게시 하기 전에 )
- … 그리고 훨씬 더.
몇 가지 단점이 있습니다.
- 아직 좋은 GUI가 많지 않습니다. 새로운 기능이며 Subversion은 훨씬 더 오랫동안 사용되어 왔으므로 개발에 인터페이스가 거의 없기 때문에 자연 스럽습니다. Mac 용 TortoiseGit 및 GitHub가 좋은 예입니다 .
현재 리포지토리의 일부 체크 아웃 / 복제는 불가능합니다 (개발 중임을 읽었습니다). 그러나 하위 모듈 지원이 있습니다.Git 1.7+는 스파 스 체크 아웃을 지원합니다 .- 비록 이것이 사실이 아니더라도 (약 1 년 전) 배우기가 더 어려울 수 있습니다. Git은 최근 인터페이스를 개선했으며 매우 사용자 친화적입니다.
가장 간단한 사용법에서 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이 실제로 빛나는 곳은 다른 사람들과 분기하고 협력하는 것입니다.
Google Tech Talk : git의 Linus Torvalds
http://www.youtube.com/watch?v=4XpnKHJAok8
Git Wiki의 비교 페이지
http://git.or.cz/gitwiki/GitSvnComparsion
글쎄, 배포되었습니다. 벤치 마크는 상당히 빠르며 (분산 특성, diff 및 log와 같은 작업은 모두 로컬이므로 물론이 경우 엄청나게 빠릅니다) 작업 폴더는 더 작습니다 (여전히 마음이 아파요).
Subversion 또는 다른 클라이언트 / 서버 개정판 제어 시스템에서 작업 할 때는 개정판 을 체크 아웃 하여 시스템에서 작업 사본을 작성해야합니다 . 리포지토리의 모양에 대한 스냅 샷을 나타냅니다. 업데이트를 통해 작업 복사본을 업데이트하고 커밋을 통해 리포지토리를 업데이트합니다.
분산 버전 제어를 사용하면 스냅 샷이 아니라 전체 코드베이스가 있습니다. 3 개월 된 버전으로 diff를 원하십니까? 문제 없습니다. 3 개월 이전 버전은 여전히 컴퓨터에 있습니다. 이것은 일이 더 빠르다는 것을 의미 할뿐 아니라 중앙 서버와의 연결이 끊긴 경우에도 이전에 사용하던 많은 작업을 수행 할 수 있습니다. 다시 말해, 주어진 개정의 스냅 샷이 아니라 전체 코드베이스가 있습니다.
Git이 하드 드라이브에서 많은 공간을 차지할 것이라고 생각하지만, 내가 본 몇 가지 벤치 마크에서 실제로는 덜 걸립니다. 방법을 묻지 마십시오. 내 말은, 그것은 Linus에 의해 지어졌으며, 내가 추측하는 파일 시스템에 대해 한두 가지 알고 있습니다.
DVCS에 대해 내가 좋아하는 요점은 다음과 같습니다.
- 깨진 것들을 저지를 수 있습니다. 게시 할 때까지 다른 사람이 볼 수 없기 때문에 중요하지 않습니다. 게시 시간은 커밋 시간과 다릅니다.
- 이 때문에 더 자주 커밋 할 수 있습니다.
- 완전한 기능성을 병합 할 수 있습니다. 이 기능에는 자체 분기가 있습니다. 이 브랜치의 모든 커밋은이 기능과 관련이 있습니다. CVCS로 DVCS를 기본값으로 사용할 수 있습니다.
- 당신은 당신의 역사를 검색 할 수 있습니다 (기능이 변경되었을 때 찾기)
- 누군가 주 저장소를 망칠 경우 풀을 실행 취소 할 수 있으며 오류를 수정할 필요가 없습니다. 병합을 지우십시오.
- 어떤 디렉토리에서나 소스 컨트롤이 필요할 때 : git init. 커밋, 변경 취소 등을 할 수 있습니다.
- 빠르다 (Windows에서도)
비교적 큰 프로젝트의 주된 이유는 포인트 3에 의해 생성 된 커뮤니케이션이 향상 되었기 때문입니다. 다른 것들은 좋은 보너스입니다.
재미있는 점은 Subversion Repos에서 프로젝트를 호스팅하지만 Git Clone 명령을 통해 프로젝트에 액세스한다는 것입니다.
Google 코드 프로젝트에서 Git으로 개발을 읽으십시오.
Google 코드는 기본적으로 Subversion을 사용하지만 개발 중에 Git을 쉽게 사용할 수 있습니다. "git svn"을 검색하면이 방법이 널리 퍼져 있음을 알 수 있으며 실험 해 보는 것도 좋습니다.
Svn 리포지토리에서 Git을 사용하면 다음과 같은 이점이 있습니다.
- 여러 컴퓨터에 분산 되어 작업을 수행 할 수 있습니다.
- 다른 사람들이 체크 아웃 할 수있는 중앙
backup/publicsvn 저장소가 있습니다. - 그리고 그들은 Git을 자유롭게 사용할 수 있습니다.
여기에 모든 대답은 프로그래머 중심적이지만 회사가 소스 코드 외부에서 개정 제어를 사용하면 어떻게됩니까? 버전 관리의 혜택을받는 소스 코드가 아닌 다른 문서가 많이 있으며 다른 CMS에서는 사용할 수 없습니다. 대부분의 프로그래머는 독립적으로 일하지 않습니다. 우리는 팀의 일원으로 회사에서 일합니다.
이를 염두에두고 클라이언트 툴링 및 교육에서 Subversion과 git 간의 사용 편의성을 비교하십시오. 나는 시나리오를 볼 수 있는 분산 버전 관리 시스템이 아닌 프로그래머로 사용하거나 설명하기 쉬울 것입니다을. 나는 git을 평가할 수 있고 실제로 프로그래머가 아닌 버전 제어가 필요한 사람들이 그것을 받아 들일 희망을 가지고 있기 때문에 잘못 입증되고 싶습니다.
그럼에도 불구하고 경영진이 중앙 집중식에서 분산 개정 제어 시스템으로 전환 해야하는 이유를 묻는다면 필요하지 않기 때문에 정직한 대답을하기가 어려울 것입니다.
면책 조항 : 나는 약 v0.29 초반에 Subversion에 관심을 갖게되었으므로 분명히 편견이 있지만 그 이후로 일한 회사는 그 사용을 장려하고 지원했기 때문에 열정으로 이익을 얻습니다. 나는 이것이 대부분의 소프트웨어 회사에서 일어나는 방식이라고 생각합니다. 너무 많은 프로그래머가 git bandwagon에 뛰어 들면서 소스 코드 외부에서 버전 제어를 사용하는 이점을 얼마나 많은 회사가 놓칠 지 궁금합니다. 팀마다 별도의 시스템이 있더라도 유지 관리, 하드웨어 및 교육 요구 사항이 증가하는 동안 (통합) 문제 추적 통합과 같은 몇 가지 이점이 빠져 있습니다.
Subversion은 여전히 훨씬 더 많이 사용되는 버전 관리 시스템이므로 도구 지원이 향상되었습니다. 거의 모든 IDE 용 성숙한 SVN 플러그인을 찾을 수 있으며 TurtoiseSVN과 같은 훌륭한 탐색기 확장 기능을 사용할 수 있습니다. 그 외에는 Michael 과 동의해야합니다 : Git은 Subversion보다 나쁘지 않습니다.
SubVersion의 영향 중 하나는 프로젝트의 각 디렉토리에 자체 폴더를 저장하는 반면 git은 루트 디렉토리에만 폴더를 저장한다는 것입니다. 그렇지 않아 그 거래의 큰하지만 그런 작은 것들이 추가 할 수 있습니다.
물론, SubVersion에는 거북이가 있습니다. 일반적으로 아주 좋습니다.
Subversion / GIT 관련 David Richards WANdisco 블로그
GIT의 출현으로 GIT 이외의 다른 것은 쓰레기라고 생각하는 일종의 DVCS 근본 주의자 인 'Gitterons'가 등장했습니다. Gitterons는 소프트웨어 엔지니어링이 자체 섬에서 발생한다고 생각하는 경우가 많으며 대부분의 조직에서 선임 소프트웨어 엔지니어를 독점적으로 고용하지 않는 경우가 종종 있습니다. 괜찮습니다.하지만 나머지 시장의 생각은 아닙니다. 그리고 그것을 증명하게되어 기쁩니다. 마침내 GIT는 시장의 3 % 미만이었고 Subversion은 5 백만 명의 사용자와 절반의 지역에 있습니다. 전체 시장.
우리가 본 문제는 Gitterons가 Subversion에서 발사 (저렴한) 샷이라는 것입니다. "Subversion은 너무 느리고 [느리게 / 크래프 / 제한적 / 냄새가 나지 않고 / 재미있는 방식으로 나를 본다]] 이제 GIT가 있고 [모든 인생에서 일하고 있습니다 / 아내가 임신했습니다 / 나중에 여자 친구가 생겼습니다. 30 년간의 시도 / 블랙 잭 테이블에서 6 번 뛰었습니다.]. 당신은 그림을 얻는다.
Git은 또한 브랜칭 및 병합을 매우 쉽게 만듭니다. Subversion 1.5는 병합 추적을 추가했지만 Git이 여전히 좋습니다. Git 분기를 사용하면 매우 빠르고 저렴합니다. 각각의 새로운 기능에 대한 브랜치를 만드는 것이 더 가능합니다. Oh 및 Git 리포지토리는 Subversion과 비교하여 저장 공간이 매우 효율적입니다.
그것은 무엇을하기 위해 필요한 사용의 용이성 / 단계에 관한 것입니다.
PC / 노트북에서 단일 프로젝트를 개발하는 경우 설정 및 사용이 훨씬 쉽기 때문에 git이 더 좋습니다. 서버가 필요 없으며 병합 할 때 저장소 URL을 계속 입력 할 필요가 없습니다.
그것이 단지 2 명이라면, git도 더 쉽다고 말합니다. 왜냐하면 서로 밀고 당길 수 있기 때문입니다.
그 이상으로 넘어 가면 전복을 갈 것입니다. 그 시점에서 '전용'서버 또는 위치를 설정해야하기 때문입니다.
SVN과 마찬가지로 git 에서도이 작업을 수행 할 수 있지만 중앙 서버와 동기화하기 위해 추가 단계를 수행해야하기 때문에 git의 이점보다 중요합니다. SVN에서는 커밋합니다. git에서는 커밋을 git push해야합니다. 추가 단계는 단순히 너무 많은 일을 끝내기 때문에 성가 시게됩니다.
SVN은 더 나은 GUI 도구의 이점을 가지고 있지만 git 생태계는 빠르게 따라 잡는 것처럼 보이므로 장기적으로 이것에 대해 걱정하지 않을 것입니다.
Easy Git 에는 Git과 SVN 의 실제 사용량을 비교할 수있는 멋진 페이지가 있으며, 이는 Git이 SVN과 비교하여 수행 할 수있는 작업에 대한 아이디어를 제공합니다. (기술적으로 이것은 Git 상단의 경량 래퍼 인 Easy 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 병합에 도움이됩니까?
중앙 서버와 지속적으로 통신 할 필요가 없기 때문에 거의 모든 명령이 1 초 이내에 실행됩니다 (물론 git push / pull / fetch는 SSH 연결을 초기화해야하기 때문에 속도가 느려집니다). 분기가 훨씬 쉽습니다 (하나의 간단한 명령은 분기하고 하나는 병합하는 간단한 명령입니다)
중앙 저장소의 물을 흐트러 뜨리지 않고 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 통합에 대한 지원이 큽니다.
Git을 사용하면보다 유연한 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/
참고 URL : https://stackoverflow.com/questions/871/why-is-git-better-than-subversion
'Programming' 카테고리의 다른 글
| 순차적으로 Gulp 작업을 순차적으로 실행하는 방법 (0) | 2020.02.22 |
|---|---|
| Android ListView 구분선의 색상을 변경하는 방법은 무엇입니까? (0) | 2020.02.22 |
| jQuery에서 로딩 스피너를 표시하는 방법은 무엇입니까? (0) | 2020.02.22 |
| android strings.xml에서 문자 및 문자를 작성하는 방법 (0) | 2020.02.22 |
| pip 및 요구 사항 파일을 사용하여 특정 패키지를 업그레이드하려면 어떻게해야합니까? (0) | 2020.02.22 |