SVN을 사용해야 합니까 아니면 Git을 사용해야 합니까?
저는 새로운 분산 프로젝트를 시작하고 있습니다.SVN 또는 Git를 사용해야 하며, 그 이유는 무엇입니까?
SVN은 하나의 레포이자 많은 고객입니다.Git는 각각 사용자가 있는 많은 클라이언트 저장소가 있는 repo입니다.외부 서버에 내용을 푸시하지 않고도 로컬에서 자신의 편집 내용을 추적할 수 있는 수준으로 분산되어 있습니다.
SVN은 Git가 각 사용자가 Gitrepo를 가지고 있고 이러한 저장소는 변경사항을 중앙에 다시 밀어넣는 것을 기반으로 하는 보다 중앙 집중식으로 설계되었습니다.이러한 이유로 Git는 개인에게 더 나은 로컬 버전 제어를 제공합니다.
TortoGit, GitExtensions 중에서 선택할 수 있습니다(또한 GitHub에 "중앙" Git 저장소를 호스팅하는 경우에는 자체 클라이언트인 GitHub for Windows)
SVN에서 벗어나려는 경우 바자르를 잠시 평가해 보는 것이 좋습니다.이것은 이 분산 요소를 가진 차세대 버전 제어 시스템 중 하나입니다.git처럼 POSIX에 의존하지 않기 때문에 네이티브 Windows 빌드가 있으며 이를 지원하는 강력한 오픈 소스 브랜드가 있습니다.
그러나 이러한 기능은 아직 필요하지 않을 수도 있습니다.분산 VCS의 기능, 장점 및 단점을 살펴봅니다.SVN 오퍼보다 더 많은 것이 필요한 경우 하나를 고려하십시오.그렇지 않다면 SVN의 (현재) 우수한 데스크톱 통합을 고수하는 것이 좋습니다.
저는 "Windows에서 git이 좋지 않다"는 개념을 이해한 적이 없습니다. Windows에서만 개발하고 git에 문제가 있었던 적은 없습니다.
저는 확실히 전복보다 기트를 추천하고 싶습니다. 그것은 단순히 훨씬 더 다양하고 전복이 결코 할 수 없는 방식으로 "오프라인 개발"을 가능하게 합니다.상상할 수 있는 거의 모든 플랫폼에서 사용할 수 있으며 사용할 수 있는 것보다 더 많은 기능이 있습니다.
다음은 Git 대 SVN(2009년 9월)에 대해 삭제한 이후 중복된 질문에 대한 답변의 사본입니다.
더 낫습니까? 일반적인 링크를 제외하고 Git Is Better.X와는 다릅니다.
하나는 분기용 저렴한 복사본을 기반으로 하는 중앙 VCS이고 다른 하나는 수정사항 그래프를 기반으로 하는 분산 VCS입니다.VCS의 핵심 개념을 참조하십시오.
첫 번째 부분은 두 프로그램(SVN과 Git)의 근본적인 목적이 동일하지만 상당히 다르게 구현된 것처럼 가장하는 잘못된 의견을 생성했습니다.
SVN과 Git의 근본적인 차이점을 명확히 하기 위해 다음과 같이 다시 표현하겠습니다.
SVN은 RCS, CVS, 그리고 마지막으로 SVN이 버전 데이터의 디렉토리를 관리하는 세 번째 수정 제어 구현입니다. SVN은 VCS 기능(라벨링 및 병합)을 제공하지만 태그는 디렉터리 복사본에 불과합니다(태그 디렉토리의 어떤 것도 "만져서는 안 됩니다"라는 점을 제외하고는). 병합은 여전히 복잡합니다.이미 병합된 내용을 기억하기 위해 추가된 메타데이터를 기반으로 합니다.
Git는 파일 콘텐츠 관리(파일을 병합하기 위해 만들어진 도구)로, DAG(Directed Acyclic Graph)의 커밋을 기반으로 진정한 버전 제어 시스템으로 진화했습니다. 분기는 데이터 기록의 일부이며 태그는 진정한 메타데이터입니다.
같은 일을 할 수 있고 같은 문제를 해결할 수 있기 때문에 근본적으로 다르지 않다고 말하는 것은...너무나 많은 수준에서 명백한 거짓.
- 복잡한 병합이 많은 경우 SVN을 사용하여 병합하는 것이 더 오래 걸리고 오류가 발생하기 쉽습니다.많은 분기를 생성해야 하는 경우, 특히 파일 수가 많은 경우(속도가 중요해지는 경우), SVN보다 Git을 사용하여 훨씬 더 쉽게 해당 분기를 관리하고 병합해야 합니다.
- 진행 중인 작업에 대해 부분 병합이 있는 경우 Git 스테이징 영역(인덱스)을 활용하여 필요한 항목만 커밋하고 나머지는 저장한 후 다른 분기로 이동합니다.
- 오프라인 개발이 필요한 경우...Git를 사용하면 다른 리포지토리에서 수행할 워크플로우가 무엇이든 상관없이 항상 로컬 리포지토리와 "온라인" 상태가 됩니다.
여전히 그 오래된 (삭제된) 답변에 대한 논평은 다음과 같이 주장했습니다.
VonC: 당신은 실행의 근본적인 차이와 목적의 차이를 혼동하고 있습니다(차이는 매우 근본적이며, 우리 둘 다 이에 분명히 동의합니다).
다입니다. 적이 있는 수 입니다. 이것이 SVN을 이전에 사용해 본 많은 팀이 Git에 유리하게 덤프할 수 있었던 이유입니다.
만약 그들이 같은 문제를 해결하지 않았다면, 이 대체 가능성은 존재하지 않았을 것입니다.
나는 이렇게 대답했습니다.
"생산성"...(컴퓨터 프로그래밍에 사용되는) 흥미로운 용어.
. Git은 SVN 하위아닙다니형유이론.
두 가지 모두에서 동일한 기술적 기능(태그, 분기, 병합)을 달성할 수 있지만 Git은 방해가 되지 않으며 도구 자체에 대해 생각하지 않고 파일 내용에 집중할 수 있습니다.
위에서 언급한 대체 가능성 정의에 대한 참조인 해당 프로그램의 바람직한 속성(정확성, 수행된 작업 등)을 변경하지 않고 SVN을 Git로 (항상) 대체할 수는 없습니다.
- 하나는 확장된 개정 도구이고, 다른 하나는 실제 버전 제어 시스템입니다.
- 하나는 간단한 병합 워크플로우와 (너무 많지 않은) 병렬 버전을 갖춘 소규모에서 중간 규모의 모노리식 프로젝트에 적합합니다. SVN은 이러한 목적을 위해 충분하며, 모든 Git 기능이 필요하지 않을 수 있습니다.
- 다른 하나는 여러 구성 요소(구성 요소당 하나의 보고서)를 기반으로 하는 중간 규모에서 대규모 프로젝트를 수행할 수 있으며, 복잡한 병합 워크플로우에서 여러 분기 간에 많은 파일을 병합하거나 분기 내 병렬 버전, 재구성 병합 등을 수행할 수 있습니다.당신은 SVN으로 할 수 있지만 Git로 하는 것이 훨씬 낫습니다.
SVN은 병합 워크플로우를 사용하여 크기에 상관없이 프로젝트를 관리할 수 없습니다.Git can.
다시 말하지만, 그들의 본질은 근본적으로 다릅니다(그러면 다른 구현으로 이어지지만 그것이 요점은 아닙니다).
하나는 리비전 제어를 디렉터리 및 파일로 보고, 다른 하나는 파일의 내용만 봅니다(빈 디렉터리가 Git!에 등록되지 않도록 너무 많이 표시).
일반적인 최종 목표는 동일할 수 있지만 동일한 방식으로 사용할 수 없으며 동일한 종류의 문제(범위 또는 복잡성)를 해결할 수도 없습니다.
거의 언급되지 않는 SVN의 2가지 주요 이점:
대용량 파일 지원.코드 외에도 SVN을 사용하여 홈 디렉토리를 관리합니다. SVN은 내 TrueCrypt 파일이 차단되지 않는 유일한 VCS입니다(500MB 이상의 파일을 효과적으로 처리하는 다른 VCS가 있으면 수정하십시오).이는 서로 다른 비교가 스트리밍되기 때문입니다(이것은 매우 중요한 점입니다).Rsync는 양방향이 아니기 때문에 허용되지 않습니다.
부분 리포지토리(하위) 체크아웃/체크인입니다.머큐리얼과 bzr은 이것을 지원하지 않으며, git의 지원은 제한적입니다.이것은 팀 환경에서는 좋지 않지만, 홈 디렉토리에서 다른 컴퓨터에서 무언가를 확인하려는 경우에는 매우 유용합니다.
그냥 제 경험입니다.
더 많은 조사를 하고 이 링크를 검토한 후: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html
(아래 일부 발췌문):
- 엄청나게 빠릅니다.제가 사용한 다른 SCM은 이를 따라가지 못했고, 서브버전, 퍼포스, 다크, 비트키퍼, 클리어케이스, CVS 등 많은 것을 사용했습니다.
- 완전 분산되어 있습니다.저장소 소유자가 제 작업 방식을 지시할 수 없습니다.랩톱에서 연결이 끊어진 상태에서 분기를 만들고 변경 내용을 커밋한 다음 나중에 다른 리포지토리와 동기화할 수 있습니다.
- 동기화는 여러 미디어에서 발생할 수 있습니다.HTTP를 통해 WebDAV를 통해, FTP를 통해 또는 메시지 수신자가 적용할 패치를 보유한 전자 메일을 보내는 SSH 채널.중앙 저장소는 필요하지 않지만 사용할 수 있습니다.
- 지점은 하위 버전보다 훨씬 더 저렴합니다.분기를 만드는 것은 디스크에 41바이트 파일을 쓰는 것만큼 간단합니다.분기를 삭제하는 것은 해당 파일을 삭제하는 것과 마찬가지로 간단합니다.
- Subversion 브랜치와 달리, 이상한 복사본을 수행하고 복사본을 살펴볼 필요 없이 전체 내역을 수행합니다.하위 버전을 사용할 때 분기가 생성되기 전에 분기에 있는 파일의 기록을 보는 것이 항상 어색했습니다.출처: #git: spearce:저는 그 페이지에서 SVN에 대해 하나도 이해할 수 없습니다.저는 아이에스브이엔 지점을 만들었고, 역사를 검색해보니 지점에 있는 파일이 전체 역사를 보여주었습니다.
- Git에서는 분기 병합이 더 간단하고 자동입니다.하위 버전에서 마지막으로 병합한 버전이 무엇인지 기억해야 올바른 병합 명령을 생성할 수 있습니다.Git은 이것을 자동으로 수행하고 항상 올바르게 수행합니다.즉, 두 분기를 병합할 때 실수할 가능성이 적습니다.
- 분기 병합은 리포지토리의 올바른 기록의 일부로 기록됩니다.두 분기를 함께 병합하는 경우 또는 분기를 원래 트렁크에 다시 병합하는 경우 해당 병합 작업은 사용자가 수행한 것으로 재저장 기록의 일부로 기록됩니다.병합이 로그에 있을 때 누가 병합을 수행했는지는 논쟁의 여지가 없습니다.
- 저장소를 만드는 것은 간단한 작업입니다. 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 저장소를 설정합니다.으로써, 개발자들은 를 사용할지 선택할 수.git-svn)을 사용합니다.git-svn완전한 Git 솔루션의 모든 이점을 제공하는 것은 아니지만, 개별 개발자가 자신의 워크플로우를 상당히 제어할 수 있습니다.
Git가 Unix 및 Mac OS X에서 작동하는 것처럼 Windows에서도 작동하기까지는 비교적 짧은 시간이 걸릴 것이라고 생각합니다.
전복에는 Tortoo와 같은 Windows용 우수한 도구가 있습니다.탐색기 통합용 SVN 및 Visual Studio 통합용 AnkhSVN.
재미있는 것은:하위 버전 Repos에서 프로젝트를 호스팅하지만 Git Clone 명령을 통해 액세스합니다.
Google 코드 프로젝트에서 Git로 개발을 읽어보십시오.
Google 코드는 기본적으로 Subversion을 사용하지만 개발 중에 Git를 쉽게 사용할 수 있습니다."gitsvn"을 검색하는 것은 이 관행이 널리 퍼져 있다는 것을 암시하며, 우리 역시 당신이 그것을 실험해 볼 것을 권장합니다.
Git on a Svn Repository를 사용하면 다음과 같은 이점이 있습니다.
- 여러 기계에 분산되어 커밋 및 풀링 작업을 수행할 수 있습니다.
- 나는 중심이 있습니다.
backup/public다른 할 수 svn - 그리고 그들은 그들 자신을 위해 Git를 자유롭게 사용할 수 있습니다.
질문에 대한 답변은 아니지만 분산 리비전 제어의 이점을 원한다면(당신이 원하는 것처럼 들리지만) Windows를 사용하고 있다면 Gitas Mercurial이 훨씬 더 나은 Windows 지원을 제공하는 것보다 Mercurial을 사용하는 것이 좋을 것 같습니다.Mercurial에도 Mac 포트가 있습니다.
만약 당신의 팀이 이미 cvs나 svn과 같은 버전과 소스 제어 소프트웨어에 익숙하다면, 단순하고 작은 프로젝트(당신이 주장하는 것처럼)에 대해서는 SVN을 고수하는 것을 추천합니다.저는 svn이 정말 편하지만, 현재 django에서 진행 중인 전자 상거래 프로젝트를 위해 git 작업을 하기로 결정했습니다(저는 적어도 한 명의 다른 개발자와 협업하기 위해 밀고 당기는 중앙 집중식 레포를 사용합니다).다른 개발자는 SVN에 익숙하고, 다른 개발자들의 경험은 다를 수 있지만, 우리 둘 다 이 작은 프로젝트를 위해 기트를 수용하는 데 정말로 힘든 시간을 보내고 있습니다.(우리 둘 다 리눅스 사용자입니다. 문제가 중요하다면 말이죠.)
물론 마일리지는 다를 수 있습니다.
요점은 Git는 분산 VCS이고 Subversion은 중앙 집중식이라는 것입니다.분산 VCS는 조금 더 이해하기 어렵지만 많은 이점이 있습니다.이러한 장점이 필요하지 않다면 Subversion이 더 나은 선택일 수 있습니다.
또 다른 질문은 도구 지원입니다.사용하려는 툴에서 더 잘 지원되는 VCS는 무엇입니까?
편집: 3년 전에 저는 이렇게 대답했습니다.
Git는 현재 Cygwin 또는 MSYS를 통해서만 Windows에서 작동합니다.버전은 처음부터 Windows를 지원했습니다.Git의 대부분의 개발자들이 리눅스로 작업하고 처음부터 이식성을 염두에 두지 않았기 때문에 윈도우용 Git 솔루션이 당신에게 효과가 있을 수 있기 때문에 문제가 있을 수 있습니다.현재로서는 Windows에서 개발하기 위해 Subversion을 선호합니다.몇 년 후면 이것은 무관할지도 모릅니다.
이제 세상은 조금 변했습니다.Git는 현재 윈도우에 잘 구현되어 있습니다.윈도우즈에서 충분히 테스트하지는 않았지만(이 시스템을 더 이상 사용하지 않기 때문에) 모든 주요 VCS(SVN, Git, Mercurial, Baza)가 현재 올바른 윈도우즈 구현을 수행하고 있다고 확신합니다.SVN의 이점은 사라졌습니다.다른 점(중앙 집중식 vs.분산 및 공구 지원 점검)이 유효합니다.
물입니다론▁defin.svn 시민이기 git(자세한 내용은 http://en.wikipedia.org/wiki/Git_(software)#Portability 참조).
업데이트: 링크가 끊겨서 죄송합니다. SO가 괄호가 포함된 URI로 작업하도록 하는 것을 포기했습니다.[지금 링크 수정됨. -ed]
저는 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(서버의 저장소에서 변경 사항을 수시로 커밋해야 하는 경우)과는 다릅니다.
내가 정말 깃과 함께 가야 하는지 결정하는 것을 도와줄 수 있는 사람?
결론은 다음과 같습니다.
개발이 선형적으로 진행됩니까?그렇다면 Subversion을 계속해야 합니다.
반면에 개발이 선형적이지 않을 경우, 서로 다른 변경사항에 대한 분기를 생성한 다음 이러한 변경사항을 주 개발 라인(Git에 마스터 분기로 알려져 있음)에 다시 병합해야 합니다. 그러면 Git이 훨씬 더 많은 작업을 수행할 수 있습니다.
Bzr 먹어봤어요?
꽤 괜찮군요, 코노니컬(우분투를 만드는 사람들)이 시장에서 다른 것이 마음에 들지 않아서 만들었어요...
질문을 확장하여 Git이 MacOS에서 잘 작동하는지 물어봐도 될까요?
댓글에 대한 회신:소식을 전해주셔서 감사합니다, 저는 그것을 시도해 보기를 고대하고 있었습니다.집에 있는 맥에 설치하겠습니다.
유튜브에 이것에 대한 흥미로운 영상이 있습니다.리누스 토왈즈가 직접 쓴 글입니다.구글 테크 토크: 리누스 토르발스 송짓.
다른 사람들이 지적한 바와 같이, Windows에서는 SVN이 좋은 선택인 것 같습니다.
일부 개발자가 GIT를 사용하려고 하는 경우에는 항상 GIT-SVN을 사용하여 SVN 저장소가 GIT 저장소에 다시 생성될 수 있습니다.그런 다음 GIT와 로컬로 작업한 다음 SVN을 사용하여 변경 사항을 기본 저장소에 게시할 수 있습니다.
DVCS를 사용해야 합니다. 소스 관리의 비약적인 발전과 같습니다.개인적으로 저는 모노톤을 사용하고 있으며 개발 시간이 끝이 없습니다.Windows, Linux 및 Mac용으로 사용하고 있으며 매우 안정적입니다.저는 심지어 각 플랫폼에서 프로젝트를 밤마다 빌드하는 빌드봇도 가지고 있습니다.
DVCS가 배포되는 동안 일반적으로 사용자가 변경사항을 전달하거나 전달할 수 있는 중앙 서버를 만듭니다.
언급URL : https://stackoverflow.com/questions/161541/should-i-use-svn-or-git
'programing' 카테고리의 다른 글
| Swift에서 UI 버튼 이미지를 변경하는 방법 (0) | 2023.05.21 |
|---|---|
| HttpWebRequest 및 HttpWebResponse에서 HttpStatus 코드 번호(200, 301, 404 등) 가져오기 (0) | 2023.05.21 |
| Excel의 VBA 기능이 범위를 반환할 수 있습니까? (0) | 2023.05.21 |
| 일별 그룹 내 MongoDB 집계 (0) | 2023.05.21 |
| Cocoapod를 사용한 Xcode 장치 테스트 (0) | 2023.05.21 |