Git이 Subversion보다 나은 이유는 무엇입니까?
https://stackoverflow.com/questions/871
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian해결책
Git은 Subversion보다 낫지 않습니다.하지만 더 나쁘지도 않습니다.그것은 다르다.
가장 큰 차이점은 분산되어 있다는 것입니다.당신이 이동 중인 개발자이고 랩톱에서 개발하고 3시간 전에 돌아갈 수 있도록 소스 제어 기능을 갖고 싶다고 상상해 보십시오.
Subversion을 사용하면 문제가 발생합니다.SVN 리포지토리가 접근할 수 없는 위치(회사 내, 현재 인터넷에 연결되어 있지 않음)에 있을 수 있으므로 커밋할 수 없습니다.코드의 복사본을 만들려면 문자 그대로 복사/붙여넣기해야 합니다.
Git을 사용하면 이런 문제가 발생하지 않습니다.로컬 복사본은 저장소이므로 이를 커밋하고 소스 제어의 모든 이점을 얻을 수 있습니다.기본 저장소에 다시 연결되면 이에 대해 커밋할 수 있습니다.
처음에는 좋아 보이지만 이 접근 방식에는 복잡성이 추가된다는 점을 명심하세요.
Git은 "새롭고, 빛나고, 멋진" 것 같습니다.그것은 결코 나쁘지 않습니다(결국 Linus가 Linux 커널 개발을 위해 그것을 쓴 이유가 있습니다). 그러나 많은 사람들이 그것이 새롭고 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은 분산화되었을 때 정말 빛을 발합니다.집에 서버가 있고 이동 중에 노트북이 있는데 여기서는 SVN이 제대로 작동하지 않습니다.SVN을 사용하면 저장소에 연결되어 있지 않으면 로컬 소스 제어를 가질 수 없습니다(예, SVK 또는 저장소를 복사하는 방법을 알고 있습니다).Git에서는 이것이 기본 모드입니다.하지만 이는 추가 명령입니다(git commit은 로컬로 커밋하는 반면 git push Origin master는 마스터 브랜치를 "origin"이라는 원격으로 푸시합니다).
위에서 말했듯이 :Git은 복잡성을 추가합니다.저장소를 생성하는 두 가지 모드(체크아웃 및 체크아웃)복제, 커밋 대푸시...어떤 명령이 로컬에서 작동하는지, 어떤 명령이 "서버"에서 작동하는지 알아야 합니다(대부분의 사람들이 여전히 중앙 "마스터 저장소"를 좋아한다고 가정합니다).
또한 적어도 Windows에서는 도구가 여전히 부족합니다.예, Visual Studio AddIn이 있지만 여전히 msysgit과 함께 git bash를 사용합니다.
SVN은 배우기가 훨씬 간단하다는 장점이 있습니다.생성, 커밋 및 체크아웃 방법을 알고 있고 갈 준비가 되어 분기, 업데이트 등과 같은 항목을 선택할 수 있는 경우 저장소에 대한 모든 변경 사항이 있습니다.나중에.
Git은 일부 개발자가 항상 마스터 리포지토리에 연결되어 있지 않은 경우 훨씬 더 적합하다는 장점이 있습니다.또한 SVN보다 훨씬 빠릅니다.그리고 내가 들은 바로는 분기 및 병합 지원이 훨씬 더 좋습니다(이것이 작성된 핵심 이유이기 때문에 예상할 수 있는 것입니다).
이는 또한 Git이 오픈 소스 프로젝트에 완벽하게 적합하기 때문에 인터넷에서 그렇게 많은 화제를 모으는 이유를 설명합니다.Fork하고 변경 사항을 자신의 Fork에 커밋한 다음 원래 프로젝트 관리자에게 변경 사항을 가져오도록 요청하세요.Git을 사용하면 이것이 작동합니다.정말, Github에서 시도해 보세요. 정말 마법같습니다.
내가 보는 것은 Git-SVN 브리지입니다.중앙 저장소는 Subversion 저장소이지만 개발자는 Git을 사용하여 로컬로 작업하고 브리지는 변경 사항을 SVN에 푸시합니다.
하지만 이렇게 긴 추가 내용에도 불구하고 저는 여전히 핵심 메시지를 고수합니다.Git은 더 좋거나 나쁘지 않은 것이 아니라 단지 다를 뿐입니다."오프라인 소스 제어"가 필요하고 이를 배우는데 추가 시간을 할애하려는 의지가 있다면 정말 좋습니다.그러나 엄격하게 중앙 집중화된 소스 제어가 있거나 동료가 관심이 없기 때문에 처음에 소스 제어를 도입하는 데 어려움을 겪고 있다면 SVN의 단순성과 뛰어난 도구(적어도 Windows에서는)가 빛을 발할 것입니다.
다른 팁
Git을 사용하면 모든 사람이 자신만의 저장소를 갖고 있기 때문에 오프라인으로 거의 모든 작업을 수행할 수 있습니다.
브랜치를 만들고 브랜치 사이를 병합하는 것은 정말 쉽습니다.
프로젝트에 대한 커밋 권한이 없더라도 온라인으로 자체 저장소를 보유하고 패치에 대한 "푸시 요청"을 게시할 수 있습니다.패치를 좋아하는 모든 사람은 공식 유지관리자를 포함하여 해당 패치를 자신의 프로젝트에 가져올 수 있습니다.
프로젝트를 포크하고, 수정하고, HEAD 브랜치의 버그 수정 사항을 계속 병합하는 것은 간단한 일입니다.
Git은 Linux 커널 개발자를 위해 작동합니다.이는 정말 빠르며(반드시 그래야 함) 수천 명의 기여자로 확장된다는 것을 의미합니다.Git은 또한 더 적은 공간을 사용합니다(Mozilla 저장소의 경우 최대 30배 더 적은 공간).
Git은 매우 유연하고 매우 TIMTOWTDI입니다(이를 수행하는 방법은 여러 가지가 있습니다).원하는 워크플로를 사용할 수 있으며 Git이 이를 지원합니다.
마지막으로, GitHub, Git 리포지토리를 호스팅하기 위한 훌륭한 사이트입니다.
Git의 단점:
- Git에는 더 많은 개념과 더 많은 명령이 있으므로 배우기가 훨씬 어렵습니다.
- 개정판에는 Subversion과 같은 버전 번호가 없습니다.
- 많은 Git 명령은 비밀스럽고 오류 메시지는 사용자에게 매우 친숙하지 않습니다.
- 좋은 GUI가 부족합니다(예: 훌륭한 거북이SVN)
다른 답변은 Git의 핵심 기능을 훌륭하게 설명했습니다.하지만 그것도 너무 많아 작은 Git이 더 잘 작동하고 내 삶을 더 건전하게 유지하는 데 도움이 되는 방식입니다.다음은 몇 가지 작은 사항입니다.
- Git에는 'clean' 명령이 있습니다.SVN은 디스크에 추가 파일을 얼마나 자주 덤프할지 고려할 때 이 명령이 절실히 필요합니다.
- Git에는 'bisect' 명령이 있습니다.좋네요.
- SVN은 모든 단일 폴더에 .svn 디렉터리를 생성합니다(Git은 하나 .git 디렉토리).여러분이 작성하는 모든 스크립트와 수행하는 모든 grep은 이러한 .svn 디렉터리를 무시하도록 작성되어야 합니다.또한 파일의 정상적인 복사본을 얻으려면 전체 명령("svn 내보내기")이 필요합니다.
- SVN에서는 각 파일 및 폴더가 다른 개정판이나 분기에서 나올 수 있습니다.처음에는 이러한 자유가 있다는 것이 좋은 것처럼 들립니다.그러나 이것이 실제로 의미하는 바는 지역 결제가 완전히 망가지는 방법이 백만 가지라는 것입니다.(예를 들어 "svn switch"가 중간에 실패하거나 명령을 잘못 입력한 경우).그리고 최악의 부분은 다음과 같습니다.파일 중 일부가 한 곳에서 오고 일부는 다른 곳에서 오는 상황에 처한 경우 "svn 상태"는 모든 것이 정상임을 알려줍니다.얼마나 이상한 일인지 알아보려면 각 파일/디렉토리에 대해 "svn info"를 수행해야 합니다."git status"가 상황이 정상이라고 알려준다면 상황이 실제로 정상이라고 믿을 수 있습니다.
- 무언가를 이동하거나 삭제할 때마다 SVN에 알려야 합니다.Git은 그것을 알아낼 것입니다.
- Git에서는 의미 체계 무시가 더 쉽습니다.패턴(예: *.pyc)을 무시하면 해당 패턴은 다음에 대해 무시됩니다. 모두 하위 디렉토리.(그러나 하나의 디렉토리에 대해 정말로 무엇인가를 무시하고 싶다면 그렇게 할 수 있습니다).SVN을 사용하면 모든 하위 디렉터리의 패턴을 무시하는 쉬운 방법이 없는 것 같습니다.
- 파일 무시와 관련된 또 다른 항목입니다.Git을 사용하면 다른 사람에게 영향을 주지 않는 "비공개" 설정 무시(.git/info/exclude 파일 사용)가 가능합니다.
"Git이 X보다 나은 이유"에서는 Git과 다른 SCM의 다양한 장단점을 간략하게 설명합니다.
간단히:
- 힘내 트랙 파일보다는 컨텐츠
- 가지가 가볍다 그리고 병합은 쉬운, 그리고 내 말은 정말 쉽다.
- 분산되어 있으며 기본적으로 모든 저장소는 분기입니다.제 생각에는 Subversion을 사용하는 것보다 동시 및 공동으로 개발하는 것이 훨씬 쉽습니다.그것은 또한 만든다 오프라인 개발 가능.
- 그것 워크플로를 강요하지 않습니다., 에서 볼 수 있듯이 위에 링크된 홈페이지, Git을 사용하면 다양한 작업 흐름이 가능합니다.Subversion 스타일의 작업 흐름은 쉽게 모방됩니다.
- Git 리포지토리는 매우 많습니다. 파일 크기가 더 작음 Subversion 저장소보다.수십 개의 ".svn" 저장소와 달리 ".git" 디렉터리는 단 하나뿐입니다(Subversion 1.7 이상 참고). 이제 단일 디렉터리를 사용합니다. Git처럼요.)
- 그만큼 각색 영역은 훌륭합니다. 이를 통해 커밋할 변경 사항을 확인하고, 부분 변경 사항을 커밋하고, 기타 다양한 작업을 수행할 수 있습니다.
- 보관 "혼란스러운" 개발을 할 때나 다른 작업(다른 브랜치에서)을 진행하는 동안 단순히 버그를 수정하고 싶을 때 매우 유용합니다.
- 당신은 할 수 있습니다 기록 다시 쓰기, 이는 패치 세트를 준비하고 실수를 수정하는 데 유용합니다(~ 전에 커밋을 게시합니다)
- …그리고 많은 더.
몇 가지 단점이 있습니다:
- 아직 좋은 GUI가 많지 않습니다.새로운 기능이고 Subversion이 훨씬 오랫동안 사용되어 왔기 때문에 개발 중인 인터페이스가 몇 가지 있기 때문에 이는 자연스러운 현상입니다.좋은 것들은 다음과 같습니다 TortoiseGit 그리고 Mac용 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이 정말 빛나는 곳은 분기하고 다른 사람들과 협력하는 것입니다.
음, 배포되었습니다.벤치마크에 따르면 훨씬 더 빠르며(분산 특성을 고려할 때 diff 및 로그와 같은 작업은 모두 로컬이므로 물론 이 경우 엄청나게 빠릅니다), 작업 폴더는 더 작습니다(여전히 놀라운 일입니다).
Subversion이나 다른 클라이언트/서버 개정 제어 시스템에서 작업할 때 기본적으로 다음과 같이 컴퓨터에 작업 복사본을 만듭니다. 체크 아웃 개정.이는 저장소의 모습에 대한 스냅샷을 나타냅니다.업데이트를 통해 작업 복사본을 업데이트하고 커밋을 통해 저장소를 업데이트합니다.
분산 버전 제어를 사용하면 스냅샷이 아니라 전체 코드베이스가 생깁니다.3개월 이전 버전과 비교하고 싶으신가요?문제 없습니다. 3개월 전 버전이 아직 컴퓨터에 남아 있습니다.이는 작업이 훨씬 더 빨라졌다는 것을 의미할 뿐만 아니라 중앙 서버와의 연결이 끊어져도 익숙한 많은 작업을 계속 수행할 수 있습니다.즉, 특정 개정판의 스냅샷뿐만 아니라 전체 코드베이스도 갖게 됩니다.
Git이 하드 드라이브에서 많은 공간을 차지할 것이라고 생각할 수도 있지만, 제가 본 몇 가지 벤치마크에 따르면 실제로는 그보다 적은 공간을 차지합니다.방법은 묻지 마세요.내 말은, 그것은 Linus가 만들었고, 내 생각에 그는 파일 시스템에 대해 한두 가지를 알고 있는 것 같습니다.
DVCS에 대해 제가 좋아하는 주요 사항은 다음과 같습니다.
- 깨진 일을 저지를 수 있습니다.게시할 때까지 다른 사람들이 해당 내용을 볼 수 없기 때문에 중요하지 않습니다.게시 시간은 커밋 시간과 다릅니다.
- 이로 인해 더 자주 커밋할 수 있습니다.
- 완전한 기능을 병합할 수 있습니다.이 기능에는 자체 분기가 있습니다.이 브랜치의 모든 커밋은 이 기능과 관련됩니다.CVCS를 사용하여 수행할 수 있지만 DVCS를 사용하면 기본값입니다.
- 기록을 검색할 수 있습니다(기능이 변경된 시기 찾기).
- 누군가가 기본 저장소를 망친 경우 가져오기를 취소할 수 있으므로 오류를 수정할 필요가 없습니다.병합을 지우면 됩니다.
- 디렉토리에 소스 제어가 필요한 경우 다음을 수행하십시오.자식 초기화 .변경 사항을 커밋하고 실행 취소하는 등의 작업을 수행할 수 있습니다.
- 빠릅니다 (Windows에서도)
상대적으로 큰 프로젝트의 주된 이유는 포인트 3을 통해 향상된 의사소통이 가능하기 때문입니다.다른 것들은 좋은 보너스입니다.
재미있는 점은 다음과 같습니다.저는 Subversion Repos에서 프로젝트를 호스팅하지만 Git Clone 명령을 통해 프로젝트에 액세스합니다.
읽어주세요 Google 코드 프로젝트에서 Git을 사용하여 개발
Google 코드는 기본적으로 전복을 말하지만 개발 중에 GIT를 쉽게 사용할 수 있습니다."git svn"을 찾는 것은이 관행이 널리 퍼져 있음을 시사하며, 우리는 당신도 그것을 실험하는 것을 권장합니다.
Svn 저장소에서 Git을 사용하면 다음과 같은 이점이 있습니다.
- 나는 일할 수 있다 분산 여러 기계에서
- 나는 본부
backup/public다른 사람들이 확인할 수 있는 svn 저장소 - 그리고 Git을 자유롭게 사용할 수 있습니다.
여기에 있는 모든 대답은 예상대로 프로그래머 중심입니다. 그러나 회사가 소스 코드 외부에서 개정 제어를 사용하면 어떻게 될까요?버전 제어의 이점을 누리고 다른 CMS가 아닌 코드에 가깝게 존재해야 하는 소스 코드가 아닌 문서가 많이 있습니다.대부분의 프로그래머는 고립되어 일하지 않습니다. 우리는 팀의 일원으로 회사를 위해 일합니다.
이를 염두에 두고 클라이언트 도구 및 교육 모두에서 Subversion과 git의 사용 편의성을 비교해 보세요.시나리오를 볼 수 없습니다. 어느 분산 개정 제어 시스템은 프로그래머가 아닌 사람에게 사용하거나 설명하기가 더 쉬울 것입니다.나는 틀렸다는 것을 증명하고 싶습니다. 왜냐하면 그렇게 하면 git을 평가할 수 있고 실제로 프로그래머가 아닌 버전 제어가 필요한 사람들이 이를 받아들일 수 있기를 바랍니다.
그럼에도 불구하고 경영진이 중앙 집중식에서 분산 개정 관리 시스템으로 전환해야 하는 이유를 묻는다면 솔직한 대답을 하기가 어려울 것입니다. 왜냐하면 그것이 필요하지 않기 때문입니다.
부인 성명:나는 초기(v0.29 경)에 Subversion에 관심을 갖게 되었기 때문에 분명히 편견이 있지만, 그 이후로 내가 일해온 회사들은 내가 Subversion 사용을 장려하고 지원했기 때문에 나의 열정으로부터 이익을 얻고 있습니다.나는 이것이 대부분의 소프트웨어 회사에서 일어나는 방식이라고 생각합니다.너무 많은 프로그래머가 git의 편에 서는 가운데, 소스 코드 외부에서 버전 제어를 사용하는 이점을 놓칠 회사가 얼마나 될지 궁금합니다.서로 다른 팀을 위한 별도의 시스템이 있더라도 유지 관리, 하드웨어 및 교육 요구 사항이 늘어나면서 (통합) 문제 추적 통합과 같은 일부 이점을 놓치게 됩니다.
나를 짜증나게 하는 SubVersion의 한 가지 점은 프로젝트의 각 디렉터리에 자체 폴더를 두는 반면 git은 루트 디렉터리에 폴더 하나만 두는 것입니다.그렇지 않다 저것 큰 일이지만 그런 작은 일들이 합쳐집니다.
물론 SubVersion에는 Tortoise가 있는데, 이는 [보통] 매우 훌륭합니다.
Subversion/GIT에 대한 David Richards WANdisco 블로그
GIT의 출현으로 인해 GIT 이외의 것은 쓰레기라고 생각하는 일종의 DVCS 근본주의자인 'Gitterons'가 탄생했습니다.Gitterons는 소프트웨어 엔지니어링이 그들 자신의 섬에서 이루어진다고 생각하고 대부분의 조직이 수석 소프트웨어 엔지니어를 독점적으로 고용하지 않는다는 사실을 종종 잊어버리는 것 같습니다.괜찮습니다. 하지만 나머지 시장에서는 그렇게 생각하지 않습니다. 저는 이를 증명하게 되어 기쁩니다.마지막 모습을 보면 GIT의 시장 점유율은 3% 미만인 반면 Subversion의 사용자 수는 500만 명에 이르고 전체 시장의 절반 정도입니다.
우리가 본 문제는 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 commit을 한 다음 git push를 해야 합니다.추가 단계는 너무 많이 수행하게 되므로 짜증스럽습니다.
SVN은 더 나은 GUI 도구라는 이점도 있지만 git 생태계가 빠르게 따라잡는 것 같기 때문에 장기적으로는 이에 대해 걱정하지 않을 것입니다.
Git과 DVCS는 일반적으로 모든 사람이 자신만의 브랜치를 갖고 있기 때문에 개발자가 서로 독립적으로 많은 코딩을 수행하는 데 적합합니다.하지만 다른 사람의 변경 사항이 필요한 경우 해당 사람이 자신의 로컬 저장소에 커밋한 다음 해당 변경 집합을 여러분에게 푸시하거나 여러분이 다른 사람에게서 가져와야 합니다.
내 생각에 따르면 중앙 집중식 릴리스와 같은 작업을 수행하면 DVCS가 QA 및 릴리스 관리 작업을 더 어렵게 만든다고 생각합니다.누군가는 다른 모든 사람의 저장소에서 푸시/풀을 수행하고 이전에 초기 커밋 시간에 해결되었을 충돌을 해결한 다음 빌드를 수행하고 다른 모든 개발자가 자신의 저장소를 다시 동기화하도록 하는 일을 담당해야 합니다.
물론 이 모든 것은 인간의 프로세스를 통해 해결될 수 있습니다.DVCS는 몇 가지 새로운 편의를 제공하기 위해 중앙 집중식 버전 제어로 수정된 문제를 해결했습니다.
저는 Git이 중대형 팀의 개발자와 개발자 간의 커뮤니케이션에 실제로 도움이 되기 때문에 좋아합니다.분산 버전 관리 시스템으로서 푸시/풀 시스템을 통해 개발자가 단일 프로젝트에서 작업하는 대규모 개발자 풀을 관리하는 데 도움이 되는 소스 코드 생태계를 생성할 수 있도록 돕습니다.
예를 들어, 5명의 개발자를 신뢰하고 해당 저장소에서만 코드를 가져옵니다.각 개발자는 코드를 가져오는 자체 신뢰 네트워크를 가지고 있습니다.따라서 개발은 코드 책임이 개발 커뮤니티 간에 공유되는 개발자의 신뢰 구조를 기반으로 합니다.
물론 여기의 다른 답변에서 언급된 다른 이점도 있습니다.
이에 대한 몇 가지 답변이 암시되어 있지만 두 가지 사항을 명시적으로 밝히고 싶습니다.
1) 선택적 커밋을 수행하는 기능(예: git add --patch).작업 디렉터리에 동일한 논리적 변경 사항이 아닌 여러 변경 사항이 포함된 경우 Git을 사용하면 변경 사항 중 일부만 포함하는 커밋을 매우 쉽게 만들 수 있습니다.Subversion을 사용하면 어렵습니다.
2) 변경 사항을 공개하지 않고 커밋할 수 있는 능력.Subversion에서는 모든 커밋이 즉시 공개되므로 취소할 수 없습니다.이는 개발자가 "초기에 커밋하고 자주 커밋"하는 능력을 크게 제한합니다.
Git은 단순한 VCS 그 이상입니다.패치 개발을 위한 도구이기도 합니다.Subversion은 단지 VCS일 뿐입니다.
Subversion이 좋은 것 같아요..병합을 시작할 때까지 ..아니면 복잡한 일을 하든가..또는 Subversion이 복잡하다고 생각하는 작업을 수행합니다(특정 파일을 망친 분기를 찾기 위해 쿼리를 수행하는 것과 같이 변경 사항이 있는 경우). 실제로 복사 및 붙여넣기 감지 등)...
나는 승리한 답변에 동의하지 않습니다. 주요 혜택 GIT는 오프라인 작업입니다. 확실히 유용하지만 제 사용 사례에서는 추가 기능에 가깝습니다.SVK는 오프라인에서도 작업할 수 있지만, 어느 것에 학습 시간을 투자해야 할지 의문의 여지가 없습니다.
단지 믿을 수 없을 만큼 강력하고 빠르며, 개념에 익숙해지면 매우 유용하다는 것입니다(그렇습니다. 그런 의미에서는:사용자 친화적).
병합 스토리에 대한 자세한 내용은 다음을 참조하세요.svn 병합을 돕기 위해 git-svn(또는 유사한) *그냥*을 사용하시겠습니까?
중앙 서버와 지속적으로 통신할 필요가 없다는 사실 덕분에 거의 모든 명령이 1초 이내에 실행됩니다(분명히 git push/pull/fetch는 SSH 연결을 초기화해야 하기 때문에 더 느립니다).분기가 훨씬 더 쉽습니다(분기하는 간단한 명령 하나, 병합하는 간단한 명령 하나)
저는 중앙 저장소를 더럽히지 않고도 Git에서 소스 코드의 로컬 브랜치를 관리할 수 있다는 점을 정말 좋아합니다.대부분의 경우 이 작업을 수행하기 위해 Subversion 서버에서 코드를 체크아웃하고 로컬 Git 저장소를 실행합니다.Git 저장소를 초기화해도 파일 시스템이 여기저기에 쌓인 성가신 .svn 폴더로 오염되지 않는다는 점도 좋습니다.
그리고 Windows 도구 지원에 관한 한 TortoiseGit은 기본 사항을 매우 잘 처리하지만 로그를 보고 싶지 않다면 여전히 명령줄을 선호합니다.저는 Tortoise{Git|SVN}이 커밋 로그를 읽을 때 도움이 되는 방식을 정말 좋아합니다.
이것은 묻는 잘못된 질문입니다.자식의 사마귀에 초점을 맞추고 적어도 일부 사용 사례에서는 Subversion이 표면적으로 더 나은 이유에 대한 주장을 공식화하는 것은 너무 쉽습니다.git이 원래 낮은 수준의 버전 제어 구성 세트로 설계되었으며 바로크식 Linux 개발자 지향 인터페이스를 가지고 있다는 사실은 성전이 견인력과 합법성을 더 쉽게 얻을 수 있게 해줍니다.Git 지지자들은 svn이 불필요하다고 주장하는 수백만 개의 워크플로우 이점을 가지고 있습니다.곧 전체 논쟁은 중앙 집중식 대 분산식으로 구성되어 엔터프라이즈 svn 도구 커뮤니티의 이익을 제공합니다.일반적으로 기업에서 Subversion의 우월성에 대한 가장 설득력 있는 기사를 게재하는 이러한 회사는 제품의 장기적인 성공을 위해 git의 인지된 불안정성과 svn의 기업 준비 상태에 의존합니다.
하지만 문제는 다음과 같습니다. Subversion은 아키텍처의 막다른 골목입니다.
git을 사용하면 매우 쉽게 중앙 집중식 Subversion 대체를 구축할 수 있지만, svn은 2배 이상 오래 사용되었음에도 불구하고 git에서처럼 근처 어디에서나 기본 병합 추적 작업을 수행할 수 없었습니다.이에 대한 기본적인 이유 중 하나는 분기를 디렉터리와 동일하게 만들기 위한 디자인 결정입니다.원래 왜 이런 식으로 갔는지 모르겠습니다. 확실히 부분 결제가 매우 간단해졌습니다.불행하게도 이력을 제대로 추적하는 것도 불가능합니다.이제 분명히 Subversion 저장소 레이아웃 규칙을 사용하여 일반 디렉터리에서 분기를 분리해야 하며 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를 1개만 찾았습니다.Eclipse 통합이 작동하지만 공식적으로 출시되지 않았으며 공식 업데이트 사이트도 없습니다(트렁크에서 정기적으로 빌드하는 일부 외부 업데이트 사이트만 있음). http://www.jgit.org/updates) 따라서 오늘날 GIT를 사용하는 가장 선호되는 방법은 명령 줄입니다.
에릭 싱크 SourceGear는 분산 버전 제어 시스템과 비분산 버전 제어 시스템의 차이점에 대한 일련의 기사를 썼습니다.그는 가장 널리 사용되는 버전 관리 시스템의 장단점을 비교합니다.매우 흥미로운 독서입니다.
해당 글은 블로그에서 보실 수 있으며, www.ericsink.com:
좋은 Git GUI를 찾는 사람들을 위해, 신테보 스마트Git 좋은 해결책이 될 수 있습니다.독점적이지만 비상업적 용도로는 무료이며 Windows/Mac/Linux에서 실행되며 일종의 git-svn 브리지를 사용하여 SVN도 지원한다고 생각합니다.
http://subversion.wandisco.com/comComponent/content/article/1/40.html
나는 개발자들 사이에서 SVN Vs라고 말하는 것이 상당히 안전하다고 생각합니다.Git 논쟁은 한동안 격렬해졌으며 모든 사람이 어느 것이 더 나은지에 대한 자신의 견해를 가지고 있습니다.이는 2010년 및 그 이후의 Subversion에 대한 웹 세미나에서 질문에서도 제기되었습니다.
오픈 소스 이사이자 Subversion Corporation의 사장인 Hyrum Wright가 Subversion과 Git, 기타 분산 버전 제어 시스템(DVCS)의 차이점에 대해 이야기합니다.
그는 또한 WC-NG(Working Copy Next Generation)와 같은 Subversion의 향후 변경 사항에 대해 이야기합니다. 이를 통해 많은 Git 사용자가 Subversion으로 다시 전환하게 될 것이라고 생각합니다.
그의 비디오를 시청하고 이 블로그에 댓글을 달거나 포럼에 게시하여 여러분의 생각을 알려주십시오.등록은 간단하며 잠시 시간만 소요됩니다!
Windows의 Git은 이제 꽤 잘 지원됩니다.
GitExtensions를 확인하세요 = http://code.google.com/p/gitextensions/
더 나은 Windows Git 경험을 위한 매뉴얼입니다.
나는 최근에 Git land에 거주하고 있으며 개인 프로젝트를 좋아하지만 직원의 생각이 바뀌면서 긴급한 혜택 없이는 Subversion에서 작업 프로젝트를 아직 전환할 수 없습니다.게다가 우리가 사내에서 운영하는 가장 큰 프로젝트는 다음 사항에 극도로 의존하고 있습니다. svn:외부 지금까지 내가 본 바로는 Git에서는 그렇게 훌륭하고 원활하게 작동하지 않습니다.
첫째, 동시 버전 관리는 해결하기 쉬운 문제처럼 보입니다.전혀 그렇지 않습니다.그래도...
SVN은 매우 직관적이지 않습니다.힘내는 더 나쁩니다.[비꼬는 추측] 이는 동시 버전 관리와 같은 어려운 문제를 좋아하는 개발자가 좋은 UI를 만드는 데 큰 관심이 없기 때문일 수 있습니다.[/비꼬는 추측]
SVN 지지자들은 분산 버전 제어 시스템이 필요하지 않다고 생각합니다. 나도 그렇게 생각했다. 하지만 이제는 Git을 독점적으로 사용하므로 저는 믿습니다.이제 버전 관리는 단지 프로젝트를 위해 작업하는 대신 나와 팀/프로젝트 모두를 위해 작동합니다.분기가 필요할 때 분기합니다.서버에 해당 분기가 있는 분기인 경우도 있고 그렇지 않은 경우도 있습니다.내가 연구해야 할 다른 모든 장점은 말할 것도 없습니다(부분적으로는 현대 버전 제어 시스템인 UI가 부족하고 터무니없기 때문입니다).
Subversion이 Git보다 낫다고 생각하는 이유(적어도 제가 작업 중인 프로젝트에서는) 주로 유용성과 단순한 작업 흐름 때문입니다.
http://www.databasesandlife.com/why-subversion-is-better-than-git/
