왜 Git이 Subversion보다 나은가요?
저는 몇 년 동안 Subversion을 사용해왔고 SourceSafe를 사용한 후에는 Subversion이 너무 좋습니다.거북이와 결합SVN, 어떻게 더 나아질 수 있는지 정말 상상이 안 가요.
그러나 Subversion에 문제가 있으며 Git와 같은 새로운 종류의 분산 버전 제어 시스템으로 전환해야 한다고 주장하는 개발자의 수가 증가하고 있습니다.
Git은 전복 시 어떻게 개선됩니까?
Git은 Subversion보다 낫지 않습니다.하지만 더 나쁘지도 않습니다.달라요.
핵심적인 차이점은 분산되어 있다는 것입니다.여러분이 이동 중인 개발자라고 상상해 보세요. 여러분은 노트북으로 개발을 하고 3시간 전으로 돌아갈 수 있도록 소스 제어를 하고 싶습니다.
Subversion에서는 다음과 같은 문제가 발생합니다.SVN 리포지토리가 연결할 수 없는 위치에 있을 수 있습니다(회사에 있고 현재 인터넷이 없습니다). 커밋할 수 없습니다.코드를 복사하려면 문자 그대로 복사/붙여넣기를 해야 합니다.
Git를 사용하면 이 문제가 발생하지 않습니다.로컬 복사본은 리포지토리이며, 이를 커밋하고 소스 제어의 모든 이점을 얻을 수 있습니다.기본 리포지토리에 대한 연결을 되찾으면 기본 리포지토리에 대해 커밋할 수 있습니다.
이것은 처음에는 좋아 보이지만, 이 접근 방식에 추가된 복잡성을 염두에 두십시오.
Git은 "새롭고, 빛나고, 멋진" 것인 것 같습니다.결코 나쁜 것은 아니지만(리너스가 리눅스 커널 개발을 위해 작성한 이유가 있다), 저는 많은 사람들이 그것이 왜/더 나은지 실제로 알지 못하고 새 것이고 리누스 토르발스가 쓴 것이라는 이유만으로 "분산 소스 제어" 기차에 뛰어든다고 생각합니다.
서브버전은 문제가 있지만 Git, Mercurial, CVS, TFS 등의 문제도 있습니다.
편집: 이 답변은 이제 1년이 지났고 여전히 많은 지지를 받고 있기 때문에 몇 가지 설명을 더 추가하려고 합니다.이 글을 쓴 후 작년에 Git는 특히 GitHub와 같은 사이트가 실제로 시작된 이후 많은 추진력과 지지를 얻었습니다.저는 요즘 Git과 Subversion을 모두 사용하고 있는데 개인적인 통찰력을 공유하고 싶습니다.
우선, Git는 분산형으로 작업할 때 처음에는 정말 혼란스러울 수 있습니다.리모컨이란 무엇입니까?초기 저장소를 올바르게 설정하는 방법은 무엇입니까?특히 SVN의 단순한 "svnadmin create"와 비교하여 Git의 "git init"는 중앙 저장소를 설정하는 "적절한" 방법으로 보이는 매개 변수인 bare와 --shared를 취할 수 있습니다.여기에는 이유가 있지만 복잡성을 더합니다."체크아웃" 명령어의 문서화는 전환하는 사람들에게 매우 혼란스럽습니다. "적절한" 방법은 "깃 클론"인 반면 "깃 체크아웃"은 분기를 전환하는 것 같습니다.
Git은 분산되어 있을 때 정말 빛납니다.집에 서버가 있고 이동 중인 노트북이 있는데 SVN은 여기서 잘 작동하지 않습니다.SVN을 사용하면 저장소에 연결되어 있지 않으면 로컬 소스 제어를 수행할 수 없습니다(예, SVK에 대해 알고 있거나 레포를 복사하는 방법에 대해 알고 있습니다).Git에서는 기본 모드입니다.그러나 추가 명령입니다(git push origin master가 "origin"이라는 이름의 원격으로 마스터 분기를 푸시하는 반면 git commit commit은 로컬로 커밋합니다).
위에서 언급한 바와 같이 Git은 복잡성을 추가합니다.저장소를 생성하는 두 가지 모드, 체크아웃과 클론, 커밋과 푸시...로컬에서 작동하는 명령과 "서버"에서 작동하는 명령을 알아야 합니다(대부분의 사용자가 여전히 중앙 "마스터 저장소"를 좋아한다고 가정합니다).
또한 적어도 Windows에서는 툴링이 여전히 불충분합니다.예, Visual Studio AddIn이 있지만, 저는 여전히 gitbash를 msysgit와 함께 사용합니다.
SVN은 학습이 훨씬 간단하다는 장점이 있습니다.저장소가 있습니다. 저장소를 만들고, 커밋하고, 체크아웃하는 방법을 알고 있으면 나중에 분기, 업데이트 등의 작업을 수행할 수 있습니다.
Git는 일부 개발자가 항상 마스터 리포지토리에 연결되어 있지 않으면 훨씬 적합하다는 장점이 있습니다.또한 SVN보다 훨씬 빠릅니다.그리고 제가 듣기로는 지원을 분기하고 통합하는 것이 훨씬 더 낫다고 들었습니다(이것들이 작성된 핵심 이유이기 때문에 예상됩니다).
이것은 또한 Git가 오픈 소스 프로젝트에 완벽하게 적합하기 때문에 인터넷에서 많은 화제를 얻는 이유를 설명합니다. 단지 포크로 변경하고 자신의 포크로 변경 사항을 커밋한 다음 원래 프로젝트 관리자에게 변경 사항을 요청하십시오.Git와 함께라면, 이것은 그냥 효과가 있습니다.정말로, Github에서 해보세요, 그건 마술입니다.
Git-SVN Bridges도 볼 수 있습니다.중앙 저장소는 Subversion repo이지만 개발자들은 Git와 로컬로 작업하고 브리지는 변경 사항을 SVN으로 푸시합니다.
하지만 이 긴 추가 사항에도 불구하고 저는 여전히 핵심 메시지를 고수하고 있습니다.기트는 더 나은 것도 아니고 더 나쁜 것도 아닙니다. 그저 다를 뿐입니다."오프라인 소스 제어"에 대한 필요성과 그것을 배우는데 시간을 더 들일 의향이 있다면, 그것은 환상적입니다.그러나 엄격하게 중앙 집중식 소스 제어를 사용하고 있거나 동료들이 관심이 없어 소스 제어를 도입하는 데 애를 먹고 있다면 SVN의 단순성과 우수한 툴링(최소한 Windows의 경우)이 빛을 발합니다.
Git를 사용하면 오프라인에서 거의 모든 작업을 수행할 수 있습니다. 모든 사용자가 각자의 저장소를 가지고 있기 때문입니다.
지점을 만들고 지점 사이를 병합하는 것은 정말 쉽습니다.
프로젝트에 대한 커밋 권한이 없는 경우에도 자체 리포지토리를 온라인 상태로 유지하고 패치에 대한 "푸시 요청"을 게시할 수 있습니다.귀하의 패치를 좋아하는 모든 사람은 공식 유지 관리자를 포함하여 해당 패치를 프로젝트에 적용할 수 있습니다.
프로젝트를 포크하고 수정한 후 HEAD 분기에서 버그 수정을 계속하여 병합하는 것은 사소한 일입니다.
Git는 Linux 커널 개발자를 위해 작동합니다.즉, 속도가 매우 빠르고(필요에 따라) 수천 명의 기여자로 확장할 수 있습니다.Git는 또한 더 적은 공간을 사용합니다(모질라 저장소의 경우 최대 30배 더 적은 공간).
Git는 매우 유연하고 TIMTOWDI(두 가지 이상의 방법이 있습니다.)원하는 워크플로우를 사용할 수 있으며 Git이 지원할 것입니다.
마지막으로 Git 저장소를 호스팅하기에 좋은 사이트인 GitHub이 있습니다.
Git의 단점:
- Git는 더 많은 개념과 더 많은 명령을 가지고 있기 때문에 배우기가 훨씬 더 어렵습니다.
- 리비전에는 하위 버전과 같은 버전 번호가 없습니다.
- 많은 Git 명령은 암호화되어 있고 오류 메시지는 매우 사용자 친화적이지 않습니다.
- 좋은 GUI(위대한 거북이와 같은)가 부족합니다.SVN)
다른 답변들은 Git의 핵심 기능을 잘 설명했습니다(훌륭합니다).하지만 Git이 더 잘 행동하고 내 삶을 더 제정신으로 유지하는 데 도움이 되는 아주 많은 작은 방법들도 있습니다.다음은 몇 가지 작은 것들입니다.
- Git에는 '정리' 명령이 있습니다. SVN은 디스크에 추가 파일을 덤프하는 빈도를 고려하여 이 명령이 절실히 필요합니다.
- Git에는 '이등분' 명령이 있습니다.좋네요.
- SVN은 모든 폴더에 .svn 디렉터리를 생성합니다(Git는 하나의 .git 디렉터리만 생성함).이러한 .svn 디렉터리를 무시하려면 모든 스크립트와 모든 grep를 작성해야 합니다.또한 파일의 정상 복사본을 얻으려면 전체 명령("svn 내보내기")이 필요합니다.
- SVN에서 각 파일 및 폴더는 서로 다른 버전 또는 분기에서 가져올 수 있습니다.처음에는, 이런 자유를 갖는 것이 좋게 들립니다.하지만 이것이 실제로 의미하는 바는 로컬 체크아웃이 완전히 엉망이 되는 방법이 무수히 많다는 것입니다(예: "svn 스위치"가 중간에 실패하거나 명령을 잘못 입력하는 경우).가장 나쁜 점은 파일 중 일부가 한 곳에서 오고 일부가 다른 곳에서 오는 상황이 발생할 경우 "svn 상태"가 모든 것이 정상임을 알려준다는 것입니다.각 파일/디렉토리에 대해 "svn info"를 수행하여 상황이 얼마나 이상한지 알아내야 합니다."git status"가 모든 것이 정상임을 알려준다면, 당신은 모든 것이 정말 정상임을 믿을 수 있습니다.
- 당신은 무언가를 옮기거나 삭제할 때마다 SVN에게 말해야 합니다.Git는 그것을 알아낼 것입니다.
- Git에서는 의미를 무시하는 것이 더 쉽습니다.패턴(예: *.pyc)을 무시하면 모든 하위 디렉터리에 대해 무시됩니다. (하지만 하나의 디렉터리에 대해서만 무언가를 무시하려는 경우에는 무시할 수 있습니다.SVN을 사용하면 모든 하위 디렉터리에서 패턴을 무시하는 쉬운 방법이 없는 것 같습니다.
- 파일 무시와 관련된 다른 항목입니다.Git을 사용하면 다른 사람에게 영향을 주지 않는 "개인" 무시 설정(.git/info/exclude 파일 사용)을 사용할 수 있습니다.
"왜 Git이 X보다 나은가"는 Git과 다른 SCM의 다양한 장단점을 요약합니다.
간략하게:
- Git는 파일이 아닌 컨텐츠를 추적합니다.
- 나뭇가지는 가볍고 결합이 쉬우며, 제 말은 정말 쉽다는 것입니다.
- 분산되어 있습니다. 기본적으로 모든 저장소는 분기입니다.Subversion보다 동시에 그리고 공동으로 개발하는 것이 훨씬 쉽다고 생각합니다.그것은 또한 오프라인 개발을 가능하게 합니다.
- 위의 링크된 웹사이트에서 볼 수 있듯이, 그것은 어떠한 워크플로우도 강요하지 않으며, Git로 가능한 많은 워크플로우가 있습니다.하위 버전 스타일 워크플로우는 쉽게 모방할 수 있습니다.
- Git 리포지토리는 하위 버전 리포지토리보다 파일 크기가 훨씬 작습니다.수십 개의 ".svn" 저장소와 달리 하나의 ".git" 디렉터리만 있습니다(Subversion 1.7 이상은 현재 Git와 같은 단일 디렉터리를 사용합니다).
- 스테이징 영역은 훌륭합니다. 사용자가 커밋할 변경 사항을 확인하고 부분적인 변경 사항을 커밋하고 다양한 작업을 수행할 수 있습니다.
- 스태킹은 "혼란스러운" 개발을 수행하거나 (다른 지점에서) 다른 작업을 하는 동안 버그를 수정하고 싶을 때 매우 유용합니다.
- 기록을 다시 작성할 수 있습니다. 이는 패치 세트를 준비하고 오류를 수정하는 데 유용합니다(커밋을 게시하기 전).
- 그리고 더 많은 것들.
몇 가지 단점이 있습니다.
- 그것을 위한 좋은 GUI는 아직 많지 않습니다.그것은 새롭고 Subversion은 훨씬 더 오랫동안 존재해 왔기 때문에 개발 중인 몇 개의 인터페이스가 있기 때문에 이것은 자연스러운 일입니다.몇 가지 좋은 것들로는 TorothyGit과 GitHub for Mac이 있습니다.
현재 리포지토리의 부분 체크아웃/클론은 불가능합니다(개발 중이라고 들었습니다).그러나 하위 모듈 지원이 있습니다.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: Linus Torvalds on git
http://www.youtube.com/watch?v=4XpnKHJAok8
깃 위키의 비교 페이지
http://git.or.cz/gitwiki/GitSvnComparsion
음, 분산되어 있습니다.벤치마크에 따르면 훨씬 더 빠릅니다(분산된 특성을 고려할 때, diff 및 로그와 같은 작업은 모두 로컬이기 때문에 이 경우에는 당연히 훨씬 더 빠름). 그리고 작업 폴더는 더 작습니다(아직도 제 마음을 아프게 합니다).
하위 버전 또는 다른 클라이언트/서버 버전 제어 시스템을 작업할 때는 기본적으로 수정사항을 체크아웃하여 컴퓨터에 작업 복사본을 만듭니다.이것은 저장소의 모양에 대한 스냅샷을 나타냅니다.업데이트를 통해 작업 복사본을 업데이트하고 커밋을 통해 리포지토리를 업데이트합니다.
분산 버전 제어를 사용하면 스냅샷이 없고 전체 코드베이스가 있습니다.3개월 된 버전으로 디프를 하고 싶습니까?문제 없습니다, 3개월 된 버전은 아직 컴퓨터에 있습니다.이는 작업 속도가 훨씬 빠르다는 것을 의미할 뿐만 아니라 중앙 서버와의 연결이 끊어진 경우에도 익숙한 많은 작업을 수행할 수 있습니다.즉, 주어진 수정본의 스냅샷뿐만 아니라 전체 코드베이스를 가지고 있습니다.
여러분은 Git가 하드 드라이브의 공간을 많이 차지할 것이라고 생각하겠지만, 제가 본 몇 가지 벤치마크를 보면 실제로는 덜 걸립니다.어떻게 된 건지 묻지 마세요.제 말은, 라이너스가 만든 것입니다. 그는 파일 시스템에 대해 조금 알고 있습니다.
DVCS의 주요 특징은 다음과 같습니다.
- 당신은 망가진 것들을 저지를 수 있습니다.당신이 출판할 때까지 다른 사람들은 그들을 보지 않을 것이기 때문에 그것은 중요하지 않습니다.게시 시간이 커밋 시간과 다릅니다.
- 이로 인해 더 자주 범할 수 있습니다.
- 전체 기능을 병합할 수 있습니다.이 기능에는 고유한 분기가 있습니다.이 분기의 모든 커밋은 이 기능과 관련됩니다.CVCS를 사용하여 이 작업을 수행할 수 있지만 DVCS가 기본값입니다.
- 기록을 검색할 수 있습니다(기능이 변경된 시점을 찾습니다).
- 다른 사용자가 기본 리포지토리를 망치면 풀을 실행 취소할 수 있습니다. 오류를 수정할 필요가 없습니다.병합을 취소합니다.
- 디렉터리에서 소스 제어가 필요할 때 git init. 그리고 커밋, 변경 취소 등을 할 수 있습니다.
- 빠른 속도(Windows에서도 가능)
비교적 큰 프로젝트의 주된 이유는 포인트 3에 의해 만들어진 향상된 커뮤니케이션입니다.다른 것들은 좋은 보너스입니다.
재미있는 것은:하위 버전 Repos에서 프로젝트를 호스팅하지만 Git Clone 명령을 통해 액세스합니다.
Google 코드 프로젝트에서 Git로 개발을 읽어보십시오.
Google 코드는 기본적으로 Subversion을 사용하지만 개발 중에 Git를 쉽게 사용할 수 있습니다."gitsvn"을 검색하는 것은 이 관행이 널리 퍼져 있다는 것을 암시하며, 우리 역시 당신이 그것을 실험해 볼 것을 권장합니다.
Git on a Svn Repository를 사용하면 다음과 같은 이점이 있습니다.
- 여러 기계에 분산되어 커밋 및 풀링 작업을 수행할 수 있습니다.
- 나는 중심이 있습니다.
backup/public다른 할 수 svn - 그리고 그들은 그들 자신을 위해 Git를 자유롭게 사용할 수 있습니다.
여기 있는 모든 대답은 예상대로 프로그래머 중심이지만, 만약 당신의 회사가 소스 코드 밖에서 수정 제어를 사용한다면 어떻게 될까요?버전 제어의 혜택을 받는 소스 코드가 아니며 다른 CMS가 아닌 코드에 가깝게 살아야 하는 문서가 많이 있습니다.대부분의 프로그래머들은 따로따로 일하지 않습니다. 우리는 팀의 일부로서 회사를 위해 일합니다.
이러한 점을 염두에 두고 클라이언트 툴링과 교육 모두에서 Subversion과 Git 사이의 사용 편의성을 비교합니다.저는 어떤 분산된 수정 제어 시스템도 사용하거나 프로그래머가 아닌 사람에게 설명하기 더 쉬울 것이라는 시나리오를 볼 수 없습니다.저는 틀렸다는 것이 증명되기를 원합니다. 왜냐하면 저는 git을 평가할 수 있고, 실제로는 프로그래머가 아닌 버전 관리가 필요한 사람들에게 받아들여질 수 있기 때문입니다.
그럼에도 중앙 집중식 수정 관리 시스템에서 분산식 수정 관리 시스템으로 전환해야 하는 이유를 경영진이 물으면 저는 정직한 답변을 하기가 어려울 것입니다. 왜냐하면 우리는 그것이 필요하지 않기 때문입니다.
고지 사항:Subversion에 일찍(v0.29 무렵) 관심을 갖게 되어 분명히 편견을 가지고 있지만, 그 이후로 근무했던 회사들은 제가 Subversion의 사용을 장려하고 지원했기 때문에 저의 열정으로 이득을 보고 있습니다.저는 대부분의 소프트웨어 회사들이 이런 식으로 발생한다고 생각합니다.이렇게 많은 프로그래머들이 유행에 편승하면서, 얼마나 많은 회사들이 소스 코드 밖에서 버전 제어를 사용하는 것의 이점을 놓치게 될지 궁금합니다.팀별로 별도의 시스템을 보유하고 있더라도 유지보수, 하드웨어 및 교육 요구사항이 증가하면서 문제 추적 통합과 같은 몇 가지 이점을 놓치고 있습니다.
서브버전은 여전히 훨씬 더 많이 사용되는 버전 제어 시스템이며, 이는 도구 지원이 더 낫다는 것을 의미합니다.거의 모든 IDE에 사용할 수 있는 성숙한 SVN 플러그인을 찾을 수 있으며 Turtoise SVN과 같은 우수한 탐색기 확장 기능이 있습니다.그 외에는 마이클의 의견에 동의해야 할 것입니다: Git은 Subversion보다 더 낫거나 더 나쁜 것이 아니라 다릅니다.
SubVersion에 대해 짜증나는 점 중 하나는 Git이 루트 디렉터리에 하나만 두는 반면, 프로젝트의 각 디렉터리에 자체 폴더를 넣는다는 것입니다.그렇게 큰 일은 아니지만, 그런 사소한 일들이 합쳐집니다.
물론, 서브버전에는 거북이가 있는데, 이것은 [보통] 매우 좋습니다.
David Richards WANdisco Subversion / GIT에 대한 블로그
GIT의 출현은 GIT 이외의 것은 쓰레기라고 생각하는 DVCS 근본주의자들, 즉 'Gitterons'를 불러왔습니다.Gitterons는 소프트웨어 엔지니어링이 자신들의 섬에서 일어난다고 생각하는 것처럼 보이며 대부분의 조직이 고급 소프트웨어 엔지니어를 독점적으로 고용하지 않는다는 사실을 종종 잊어버립니다.그건 괜찮지만 다른 시장들이 생각하는 방식은 아닙니다. 그리고 저는 그것을 증명하게 되어 기쁩니다. GIT는 지난 조사에서 시장 점유율이 3% 미만인 반면, Subversion은 500만 명의 사용자와 전체 시장의 약 절반을 차지하고 있습니다.
우리가 본 문제는 Gitterons가 Subversion을 향해 총을 쏘고 있다는 것이었습니다."전복은 너무 느리다/빠빠르다/제한적이다/냄새가 좋지 않다/웃기는 시선으로 나를 바라본다] 그리고 지금 나는 GIT와 [내 인생에서 모든 것이 작동한다/아내가 임신했다/나는 30년 동안 노력한 끝에 여자친구를 얻었다/블랙잭 테이블에서 6번이나 우승했다]와 같은 트윗을 했습니다.당신은 이해합니다.
Git는 또한 분기 및 병합을 매우 쉽게 합니다.서브버전 1.5는 방금 병합 추적을 추가했지만 Git은 여전히 더 낫습니다.깃과 함께 가지치기는 매우 빠르고 저렴합니다.이를 통해 각 새 피쳐에 대한 분기를 생성할 수 있습니다.Oh 및 Git 저장소는 Subversion에 비해 스토리지 공간이 매우 효율적입니다.
이는 무엇인가를 수행하는 데 필요한 사용 편의성/단계에 관한 것입니다.
PC/노트북에서 단일 프로젝트를 개발하는 경우 git이 훨씬 더 낫습니다. 설정 및 사용이 훨씬 쉬우니까요.서버가 필요하지 않으며 병합할 때 리포지토리 URL을 계속 입력할 필요도 없습니다.
두 사람이면 서로 밀고 당기기만 하면 되기 때문에 기트도 더 편하다고 생각합니다.
하지만 그 이상을 달성하면, 저는 전복을 시도할 것입니다. 그 시점에서 '전용' 서버나 위치를 설정해야 하기 때문입니다.
이는 SVN과 마찬가지로 Git로도 가능하지만 중앙 서버와 동기화하기 위한 추가 단계를 수행해야 하기 때문에 Git의 이점보다 더 중요합니다.SVN에서는 그냥 커밋합니다.Git은 커밋하고 Git push해야 합니다.추가 단계는 단순히 너무 많이 수행하기 때문에 성가시게 됩니다.
SVN은 더 나은 GUI 도구의 이점도 있지만 Git 에코시스템이 빠르게 따라잡고 있는 것처럼 보이기 때문에 장기적으로 이에 대해 걱정하지 않을 것입니다.
이지기트는 실제 Git와 SVN의 사용을 비교한 멋진 페이지를 가지고 있어 SVN에 비해 Git이 무엇을 할 수 있는지(또는 더 쉽게 할 수 있는지)에 대한 아이디어를 제공합니다. (기술적으로, 이것은 이지기트 위에 가벼운 포장지인 EasyGit을 기반으로 합니다.
Git와 DVCS는 일반적으로 개발자들이 서로 독립적으로 많은 코딩을 하는 데 유용합니다. 왜냐하면 모든 개발자들은 각자의 브랜치를 가지고 있기 때문입니다.하지만 만약 당신이 다른 사람으로부터 변화가 필요하다면, 그녀는 그녀의 지역 레포에 전념해야 하고, 그녀는 그 변화를 당신에게 강요하거나 당신이 그녀에게서 그것을 제거해야 합니다.
또한 중앙 집중식 릴리스와 같은 작업을 수행할 경우 DVCS가 QA 및 릴리스 관리를 어렵게 만든다고 생각합니다.다른 모든 사용자의 리포지토리에서 푸시/풀을 수행하고, 이전에 초기 커밋 시 해결되었을 충돌을 해결한 다음 빌드를 수행하고, 다른 모든 개발자가 리포지토리를 다시 동기화하도록 하는 책임은 누군가에게 있습니다.
물론 이 모든 것은 인간 프로세스로 해결할 수 있습니다. DVCS는 새로운 편의를 제공하기 위해 중앙 집중식 버전 제어에 의해 수정된 것을 깨뜨렸습니다.
저는 Git을 좋아합니다. 왜냐하면 Git은 실제로 통신 개발자들이 중대형 팀에서 개발할 수 있도록 도와주기 때문입니다.분산 버전 관리 시스템으로서, 푸쉬/풀 시스템을 통해 개발자들이 소스 코드 에코 시스템을 만들 수 있도록 지원하여 단일 프로젝트에서 작업하는 대규모 개발자 풀을 관리할 수 있도록 지원합니다.
예를 들어, 5명의 개발자를 신뢰하고 해당 저장소에서 코드만 가져온다고 가정합니다.각각의 개발자들은 그들이 코드를 뽑아내는 곳에서 그들만의 신뢰 네트워크를 가지고 있습니다.따라서 개발은 개발 커뮤니티 간에 코드 책임을 공유하는 개발자의 신뢰 구조를 기반으로 합니다.
물론 여기 다른 답변에 언급된 다른 이점도 있습니다.
몇 가지 답변이 이를 암시했지만, 저는 두 가지 점을 분명히 하고 싶습니다.
커밋( 선적커수수예있는기능할행밋을택예▁(:)을 (예:git add --patch) 변경의 사항이 되어 있는 수행할 수 작업 디렉터리에 동일한 논리적 변경의 일부가 아닌 여러 변경 사항이 포함되어 있는 경우 Git을 사용하면 변경 사항의 일부만 포함하는 커밋을 매우 쉽게 수행할 수 있습니다.Subversion을 사용하면 어렵습니다.
변경 사항을 공개하지 않고 커밋할 수 있는 기능.전복에서는 모든 커밋이 즉시 공개되므로 취소할 수 없습니다.이는 개발자가 "조기 커밋, 자주 커밋"할 수 있는 능력을 크게 제한합니다.
Git는 단순한 VCS가 아니라 패치를 개발하는 도구이기도 합니다.하위 버전은 VCS에 불과합니다.
전복은 괜찮다고 생각합니다.합병을 시작할 때까지..복잡한 일을 하는 것도..또는 Subversion이 복잡하다고 생각하는 모든 작업을 수행합니다(예: 쿼리를 수행하여 특정 파일을 엉망으로 만든 분기, 변경 사항이 실제로 발생한 지점, 복사 및 붙여넣기 탐지 등).
저는 GIT의 주요 이점이 오프라인 작업이라고 말하면서 승소한 답변에 동의하지 않습니다. 확실히 유용하지만 제 사용 사례에 대한 추가적인 이점에 가깝습니다.SVK는 오프라인에서도 작업할 수 있지만, 학습 시간을 어느 쪽에 투자해야 하는지는 의문의 여지가 없습니다.)
단지 그것은 믿을 수 없을 정도로 강력하고 빠르며, 개념에 익숙해진 후에 매우 유용합니다(그렇습니다, 그런 의미에서: 사용자 친화적입니다).
병합 이야기에 대한 자세한 내용은 다음을 참조하십시오. git-svn(또는 유사한) *just*를 사용하여 svn 병합을 도와드릴까요?
중앙 서버와 지속적으로 통신할 필요가 없기 때문에 거의 모든 명령이 1초 이내에 실행됩니다(단순히 SSH 연결을 초기화해야 하기 때문에 git push/pull/fetch가 느립니다).분기가 훨씬 더 쉽습니다(단순한 명령 하나를 분기로, 단순한 명령 하나를 병합으로).
저는 중앙 저장소의 물을 더럽히지 않고 Git에서 소스 코드의 로컬 지점을 관리할 수 있는 것이 정말 좋습니다.대부분의 경우 서브버전 서버에서 코드를 체크아웃하고 로컬 Git 저장소를 실행하여 이를 수행합니다.Git 저장소를 초기화하는 것이 파일 시스템을 오염시키지 않는다는 것도 좋은 일입니다. svn 폴더가 여러 곳에 널려 있습니다.
그리고 Windows 도구 지원에 관한 한 TorothyGit은 기본적인 기능을 매우 잘 처리하지만 로그를 보고 싶지 않은 경우에는 명령줄을 선호합니다.나는 거북이의 방식이 정말 좋습니다.SVN}은(는) 커밋 로그를 읽을 때 도움이 됩니다.
이것은 잘못된 질문입니다.기트 사마귀에 초점을 맞추고 적어도 일부 사용 사례에서 왜 전복이 표면적으로 더 나은지에 대한 논쟁을 공식화하는 것은 너무 쉽습니다.git는 원래 낮은 수준의 버전 제어 구성 세트로 설계되었고 바로크 리눅스 개발자 지향 인터페이스를 가지고 있다는 사실은 성전이 매력을 얻고 정당성을 인식하는 것을 더 쉽게 만듭니다.Git 지지자들은 수백만 개의 워크플로우 이점을 제공하지만, svn 사용자들은 불필요하다고 주장합니다.곧 전체 토론이 중앙 집중식과 분산식으로 구성되어 엔터프라이즈 SVN 툴 커뮤니티의 이익에 부합합니다.일반적으로 기업에서 전복의 우수성에 대해 가장 설득력 있는 기사를 내는 이들 기업은 제품의 장기적인 성공을 위해 git의 불안감과 svn의 엔터프라이즈 준비 상태에 의존합니다.
하지만 여기 문제가 있습니다.전복은 건축학적 막다른 골목입니다.
반면에 git를 사용하여 중앙 집중식 버전 대체를 상당히 쉽게 구축할 수 있습니다. svn이 두 배 이상 오래 존재했음에도 불구하고 기본 병합 추적조차 git만큼 가까운 곳에서 작동하지 못했습니다.이에 대한 기본적인 이유 중 하나는 분기를 디렉터리와 동일하게 만들기로 한 설계 결정입니다.원래는 왜 이쪽으로 갔는지 모르겠네요, 부분적인 체크아웃이 굉장히 간단하네요.불행하게도 그것은 또한 역사를 제대로 추적하는 것을 불가능하게 만듭니다.하위 버전 저장소 레이아웃 규칙을 사용하여 일반 디렉터리에서 분기를 분리해야 하며, svn은 몇 가지 경험적 접근 방식을 사용하여 일상적인 사용 사례를 처리해야 합니다.하지만 이 모든 것은 매우 빈약하고 낮은 수준의 디자인 결정을 제한하는 종이에 불과합니다.(디렉토리별 디프가 아닌) 저장소별 디프를 수행할 수 있는 것은 버전 제어 시스템의 기본적이고 중요한 기능이며 내부를 크게 단순화하여 그 위에 더 스마트하고 유용한 기능을 구축할 수 있습니다.이전 버전을 확장하기 위해 얼마나 많은 노력을 기울였는지, 그리고 병합 해결과 같은 기본 작업 측면에서 현재의 VCS보다 얼마나 뒤쳐져 있는지를 확인할 수 있습니다.
다음은 Subversion이 예측 가능한 미래에 충분히 좋다고 여전히 믿는 사람들을 위한 진심 어린 불가지론적인 조언입니다.
이전 버전은 RCS와 CVS의 실수에서 배운 최신 버전의 VCS를 따라잡을 수 없습니다. 저장소 모델을 처음부터 다시 재설계하지 않는 한 기술적으로 불가능하지만 실제로는 가상화되지 않을 것입니다.최신 VCS의 기능을 사용하지 않는다고 생각하는 경우와 상관없이 대부분 다른 시스템에서는 불가능하거나 쉽게 해결할 수 없는 상황인 서브버전의 함정으로부터 사용자를 보호할 수는 없습니다.
솔루션의 기술적 열세가 svn만큼 명확한 경우는 극히 드물며, win-vs-linux나 emacs-vs-vi에 대해서는 절대로 언급하지 않겠지만, 이 경우에는 매우 명확하고 소스 제어는 개발자의 무기에서 매우 기본적인 도구이기 때문에 명확하게 명시되어야 한다고 생각합니다.조직적인 이유로 svn을 사용해야 하는 요구 사항과 상관없이 모든 svn 사용자가 논리적인 마인드로 인해 더 최신 VCS가 대규모 오픈 소스 프로젝트에만 유용하다는 잘못된 믿음을 구축하지 않도록 요청합니다.개발 작업의 특성에 관계없이 프로그래머인 경우 Git, Mercurial, Darcs 등 더 잘 설계된 VCS를 사용하는 방법을 배우면 더 효과적인 프로그래머가 될 수 있습니다.
전복은 사용하기 매우 쉽습니다.저는 지난 몇 년 동안 어떤 문제가 있거나 어떤 것이 예상대로 작동하지 않는다는 것을 발견한 적이 없습니다.또한 우수한 GUI 도구가 많이 있으며 SVN 통합에 대한 지원이 큽니다.
Git를 사용하면 VCS가 더욱 유연해집니다.모든 변경 사항을 커밋하는 원격 저장소에서 SVN과 동일한 방식으로 사용할 수 있습니다.그러나 대부분 오프라인에서 사용할 수 있으며 변경 사항을 원격 저장소에만 수시로 푸시할 수도 있습니다.하지만 Git은 더 복잡하고 더 가파른 학습 곡선을 가지고 있습니다.저는 처음으로 잘못된 지점에 전념하고, 간접적으로 지점을 만들거나, 오류 메시지를 수신하고, 오류에 대한 정보가 많지 않으며, 더 나은 정보를 얻기 위해 구글로 검색해야 하는 곳을 발견했습니다.마커($Id$)의 대체와 같은 간단한 것들은 작동하지 않지만 GIT는 자체 스크립트를 병합할 수 있는 매우 유연한 필터링 및 후크 메커니즘을 가지고 있으므로 필요한 모든 것과 더 많은 것을 얻을 수 있지만 문서를 읽는 데 더 많은 시간과 시간이 필요합니다;)
로컬 리포지토리에서 대부분 오프라인으로 작업하는 경우 로컬 시스템에서 무언가가 손실되면 백업이 없습니다.SVN을 사용하면 다른 서버의 백업과 동시에 원격 저장소에서 작업하는 경우가 대부분입니다.Git은 같은 방식으로 작동할 수 있지만 이것은 SVN2와 같은 것을 갖는 것이 리누스의 주요 목표는 아니었습니다.리눅스 커널 개발자와 분산 버전 제어 시스템의 필요성을 위해 설계되었습니다.
Git이 SVN보다 낫습니까?일부 버전 기록과 백업 메커니즘만 필요한 개발자는 SVN을 통해 쉽고 편안한 삶을 살 수 있습니다.개발자들은 종종 지점과 함께 작업하거나, 동시에 더 많은 버전을 테스트하거나, 대부분 오프라인으로 작업하는 경우 Git의 기능을 활용할 수 있습니다.SVN에서 찾을 수 없는 스태킹과 같은 매우 유용한 기능이 있어 삶을 더 쉽게 만들 수 있습니다.그러나 반대로 모든 사람이 모든 기능을 필요로 하는 것은 아닙니다.그래서 SVN의 사망자를 볼 수 없습니다.
Git는 더 나은 문서가 필요하며 오류 보고가 더 도움이 될 것입니다.또한 기존의 유용한 GUI는 거의 없습니다.이번에는 대부분의 Git 기능(git-cola)을 지원하는 Linux용 GUI를 1개밖에 찾지 못했습니다.이클립스 통합은 작동하고 있지만 공식적으로 출시되지 않았고 공식 업데이트 사이트도 없습니다(트렁크 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 대라고 말하는 것이 상당히 안전하다고 생각합니다.Git 논쟁은 지금까지 한동안 격렬해 왔고, 모든 사람들은 어떤 것이 더 나은지에 대한 자신만의 견해를 가지고 있습니다.이것은 2010년 서브버전과 그 이후에 대한 웹 세미나에서 질문에도 언급되었습니다.
오픈 소스 이사이자 서브버전 코퍼레이션 사장인 하이럼 라이트는 다른 분산 버전 제어 시스템(DVCS)과 함께 서브버전과 Git의 차이점에 대해 이야기합니다.
그는 또한 많은 Git 사용자들이 Subversion으로 다시 변환하게 될 것이라고 믿는 Working Copy Next Generation(WC-NG)과 같은 Subversion의 다가오는 변화에 대해 이야기합니다.
그의 비디오를 보고 이 블로그에 댓글을 달거나 포럼에 글을 올려 어떻게 생각하는지 알려주십시오.등록은 간단하며 잠시만 소요됩니다!
Git in Windows는 이제 상당히 잘 지원됩니다.
GitExtensions 확인 = http://code.google.com/p/gitextensions/
Windows Git 환경을 개선하기 위한 설명서도 제공합니다.
저는 최근에 깃랜드에 거주하고 있고, 개인적인 프로젝트를 위해 그것을 좋아하지만, 직원들에게 요구되는 생각의 변화를 고려할 때, 긴급한 혜택 없이는 아직 서브버전에서 그것으로 작업 프로젝트를 전환할 수 없을 것입니다.게다가 우리가 내부적으로 운영하는 가장 큰 프로젝트는 svn에 매우 의존적입니다. 제가 지금까지 본 바로는 Git에서 그렇게 훌륭하고 원활하게 작동하지 않는 외부입니다.
첫째, 동시 버전 제어는 해결하기 쉬운 문제로 보입니다.전혀 아닙니다.어쨌든...
SVN은 매우 직관적이지 않습니다.기트는 더 심합니다.[스캐너-스펙션이것은 동시 버전 제어와 같은 어려운 문제와 마찬가지로 개발자들이 좋은 UI를 만드는 데 큰 관심이 없기 때문일 수 있습니다.[/비공식적인 추측]
SVN 지지자들은 분산 버전 제어 시스템이 필요하지 않다고 생각합니다.저도 그렇게 생각했어요.하지만 이제 우리가 Git를 독점적으로 사용하기 때문에, 저는 신자입니다.이제 버전 관리는 프로젝트를 위해 일하는 것이 아니라 저와 팀/프로젝트를 위해 작동합니다.저는 지점이 필요할 때 지점을 합니다.서버에 해당 분기가 있는 분기일 수도 있고 그렇지 않을 수도 있습니다.제가 공부하러 가야 할 다른 모든 장점은 말할 것도 없습니다(일부는 현대 버전 제어 시스템인 UI의 난해하고 터무니없는 부족 덕분입니다).
주로 유용성과 단순한 워크플로우 때문에 서브버전이 Git보다 낫다고 생각하는 이유:
http://www.databasesandlife.com/why-subversion-is-better-than-git/
언급URL : https://stackoverflow.com/questions/871/why-is-git-better-than-subversion
'programing' 카테고리의 다른 글
| Eclipse Classic에서 Eclipse Marketplace를 설치하려면 어떻게 해야 합니까? (0) | 2023.05.26 |
|---|---|
| git는 파일을 어떻게 저장합니까? (0) | 2023.05.26 |
| "forach" 루프의 반복을 건너뛰려면 어떻게 해야 합니까? (0) | 2023.05.21 |
| VB.NET에서 공유 변수는 어떤 용도로 사용됩니까? (0) | 2023.05.21 |
| pathlib를 사용하여 모든 하위 디렉터리를 재귀적으로 반복합니다. (0) | 2023.05.21 |