GIT와 CVS의 차이

GIT와 CVS의 차이

Git와 CVS 버전 제어 시스템의 차이점은 무엇입니까?

저는 10년 넘게 행복하게 CVS를 사용해 왔고, 지금은 Git가 훨씬 낫다는 말을 들었습니다.누가 그 둘의 차이점이 무엇인지, 그리고 왜 한쪽이 다른 쪽보다 더 나은지 설명해 주실 수 있나요?

주요 차이점은 (다른 응답에서 이미 언급했듯이) CVS는 (구) 중앙 집중형 버전 제어 시스템인 반면 Git는 분산되어 있다는 것입니다.

그러나 단일 개발자, 단일 머신(단일 계정)에서 버전 제어를 사용하더라도 Git와 CVS 사이에는 몇 가지 차이점이 있습니다.

• 리포지토리를 설정하는 중입니다.Git은 저장소를 다음에 저장합니다..git프로젝트의 최상위 디렉터리에 있는 디렉터리. CVS는 다양한 프로젝트(모듈)에 대한 버전 제어 정보를 저장하는 중앙 위치인 CVSROOT를 설정해야 합니다.사용자를 위한 이러한 설계의 결과는 기존 소스를 버전 제어로 가져오는 것이 Git의 "git init & git add . & git commit"처럼 간단한 반면 CVS에서는 더 복잡하다는 것입니다.

• 원자 작동.처음에 CVS는 파일별 RCS 버전 제어 시스템을 중심으로 한 일련의 스크립트였기 때문에 CVS에서 커밋(및 기타 작업)은 원자성이 아닙니다. 저장소에 대한 작업이 중간에 중단되면 저장소가 일관되지 않은 상태로 유지될 수 있습니다.Git에서 모든 연산은 원자적 연산입니다. 전체적으로 성공하거나 변경 없이 실패합니다.

• 세트를 변경합니다.CVS의 변경 사항은 파일 단위로 이루어지며 Git의 변경 사항(커밋)은 항상 전체 프로젝트를 나타냅니다.이것은 매우 중요한 패러다임의 변화입니다.이것의 결과 중 하나는 Git에서 전체 변경을 되돌리거나 되돌리는 것이 매우 쉽다는 것입니다. 다른 결과는 CVS에서는 부분 체크아웃이 쉽지만 현재 Git에서는 거의 불가능하다는 것입니다.변경 사항이 파일 단위로 함께 그룹화되어 있다는 사실은 CVS에서 커밋 메시지를 위한 GNU Changelog 형식의 발명으로 이어졌습니다. Git 사용자는 변경 사항을 설명(요약)하는 한 줄, 빈 줄, 변경 사항에 대한 더 자세한 설명이 이어지는 다른 규약을 사용합니다.

• 이름 수정본/버전 번호.CVS에서 파일 단위로 변경된다는 사실과 관련된 또 다른 문제가 있습니다. 버전 번호(키워드 확장에서 때때로 볼 수 있듯이 아래 참조)는 1.4가 주어진 파일이 변경된 횟수를 반영합니다.Git에서 프로젝트의 각 버전 전체(각 커밋)에는 SHA-1 id로 지정된 고유한 이름이 있습니다. 보통 처음 7-8자로 커밋을 식별하기에 충분합니다(중앙 번호 지정 권한이 필요한 분산 버전 제어 시스템의 버전에는 간단한 번호 지정 체계를 사용할 수 없습니다).CVS에서 버전 번호나 심볼 이름이 프로젝트 전체의 상태를 나타내려면 태그를 사용합니다. 프로젝트의 일부 버전에 'v1.5.6-rc2'와 같은 이름을 사용하려면 Git에서도 마찬가지입니다.하지만 Git의 태그는 훨씬 사용하기 쉽습니다.

• 가지치기가 쉽습니다.제 생각에 CVS의 지점들은 너무 복잡하고 다루기 어렵습니다.전체 저장소 분기에 대한 이름을 가지려면 분기에 태그를 지정해야 합니다(그리고 파일별 처리로 인해 올바르게 기억한다면 실패할 수도 있습니다).여기에 CVS에는 병합 추적 기능이 없기 때문에 병합 및 분기 지점을 기억하거나 수동으로 태그를 지정해야 하며, "cvs update -j"에 대한 올바른 정보를 수동으로 제공하여 분기를 사용하기가 불필요합니다.Git에서 분기를 생성하고 병합하는 것은 매우 쉽습니다. Git은 필요한 모든 정보를 스스로 기억합니다(따라서 분기를 병합하는 것은 "git merge branchname"만큼 쉽습니다).분산 개발은 자연스럽게 여러 지점으로 이어지기 때문에 그렇게 해야 했습니다.

즉, 토픽 분기를 사용할 수 있습니다. 즉, 별도의 피쳐 분기에서 여러 단계로 별도의 피쳐를 개발할 수 있습니다.

• 추적 이름을 변경(및 복사)합니다.CVS에서는 파일 이름 변경이 지원되지 않으며 수동 이름 변경으로 인해 기록이 두 번으로 깨지거나 이름 변경 전에 프로젝트의 상태를 올바르게 복구할 수 없는 잘못된 기록이 발생할 수 있습니다.Git는 내용과 파일명의 유사성을 기반으로 휴리스틱 이름 변경 탐지 기능을 사용합니다(이 솔루션은 실제로도 잘 작동합니다).파일 복사 탐지를 요청할 수도 있습니다.이는 다음을 의미합니다.

• 지정된 커밋을 검사할 때 일부 파일의 이름이 변경되었다는 정보를 얻을 수 있습니다.

• merging은 이름을 정확하게 고려합니다(예: 파일 이름이 하나의 분기에서만 변경된 경우).

• "git blame"은 파일 내용의 줄 단위 이력을 보여주는 도구로서, "cvs 주석"과 더 나은 (좋은) 동등한 것으로, 이름을 바꾸면서 코드 이동을 따를 수 있습니다.

• 이진 파일.CVS는 이진 파일(예: 이미지)에 대한 지원이 매우 제한적이어서 사용자가 파일 이름을 기반으로 자동으로 추가할 때(또는 나중에 "cvs admin"을 사용하거나 래퍼를 통해 파일 이름을 기반으로 자동으로 추가할 때) 이진 파일을 명시적으로 표시해야 합니다.Git는 CNU diff와 다른 도구가 하는 것과 같은 방식으로 콘텐츠를 기반으로 이진 파일을 자동으로 탐지합니다. git 속성 메커니즘을 사용하여 이 탐지를 재정의할 수 있습니다.또한 바이너리 파일은 'safecrlf'의 기본값 덕분에 복구할 수 없는 망글링으로부터 안전합니다(그리고 배포에 따라 기본적으로 켜져 있을 수 있지만 종단 변환을 요청해야 한다는 사실). 그리고 Git에서 (제한된) 키워드 확장은 엄격한 'opt-in'입니다.

• 키워드 확장.Git는 CVS에 비해 매우 제한적인 키워드 집합을 제공합니다(기본값).이는 두 가지 사실 때문입니다. Git의 변경 사항은 저장소별로 변경되며 파일별로 변경되지 않으며, Git은 다른 분기로 전환할 때 변경되지 않은 파일을 수정하거나 기록의 다른 지점으로 다시 감기는 것을 피합니다.Git을 사용하여 리비전 번호를 내장하고 싶다면, 예를 들어 리눅스 커널 소스 및 Git 소스에서 GIT-VERSION-GEN 스크립트의 예를 따르는 빌드 시스템을 사용하여 이 작업을 수행해야 합니다.

• 커밋 수정.Gitact of publishing과 같은 분산 VCS에서는 커밋을 생성하는 것과 별개이기 때문에 다른 사용자에게 불편을 주지 않고 게시되지 않은 내역 부분을 변경(편집, 다시 쓰기)할 수 있습니다.특히 커밋 메시지에 오타(또는 기타 오류)가 있거나 커밋에 버그가 있는 경우 "git commit --amend"를 사용하면 됩니다.이것은 CVS에서는 가능하지 않습니다. (적어도 무거운 해킹 없이는 안됩니다.)

• 더 많은 도구.깃은 CVS보다 훨씬 더 많은 도구를 제공합니다.더 중요한 것 중 하나는 버그를 도입한 커밋(개정판)을 찾는 데 사용할 수 있는 "깃 이등분"입니다. 커밋이 작고 자체적으로 포함되어 있다면 버그가 어디에 있는지 쉽게 찾을 수 있을 것입니다.

---

만약 당신이 적어도 한 명의 다른 개발자와 공동으로 작업한다면, Git와 CVS 사이에 다음과 같은 차이점도 발견할 수 있을 것입니다.

• 병합 전 커밋 Git은 CVS와 같이 병합 전 커밋(또는 업데이트 후 커밋)이 아닌 병합 전 커밋을 사용합니다.파일을 편집할 때, 새로운 커밋(새 수정판)을 만들기 위해 준비하는 동안, 다른 사람이 같은 분기에서 새로운 커밋을 생성하고 저장소에 있는 경우, CVS는 커밋을 허용하기 전에 먼저 작업 디렉토리를 업데이트하고 충돌을 해결하도록 강요합니다.Git의 경우에는 그렇지 않습니다.먼저 커밋을 하고 상태를 버전 제어에 저장한 다음 다른 개발자 변경사항을 병합합니다.다른 개발자에게 병합 및 충돌 해결을 요청할 수도 있습니다.

선형 기록을 가지고 병합을 피하기를 원하는 경우 "깃 리베이스"(및 "깃 풀 --리베이스")를 통해 항상 커밋-병합-재추천 워크플로우를 사용할 수 있습니다. 이 워크플로우는 업데이트된 상태 위에서 변경 내용을 재생한다는 점에서 CVS와 유사합니다.하지만 당신은 항상 먼저 행동합니다.

• 중앙 저장소 필요 없음 Git를 사용하면 변경 사항을 커밋하는 단일 중앙 장소를 가질 필요가 없습니다.각 개발자는 자체 저장소(또는 더 나은 저장소: 개발을 수행하는 개인 저장소와 준비된 부분을 게시하는 공개 저장소)를 가질 수 있으며, 서로 대칭적인 방식으로 서로의 저장소를 꺼내거나 가져올 수 있습니다.반면, 대규모 프로젝트는 사회적으로 정의/지명된 중앙 저장소를 보유하는 것이 일반적이며, 이 저장소를 통해 모든 사람이 (변경 사항을 받는) 작업을 수행합니다.

---

마지막으로 Git은 많은 수의 개발자들과의 협업이 필요할 때 더 많은 가능성을 제공합니다.아래에는 프로젝트의 다양한 관심 단계 및 위치에 대한 Git의 CVS 간 차이가 있습니다(CVS 또는 Git을 사용한 버전 제어 하에서).

• 잠복. 프로젝트에서 최신 변경 사항만 얻는데 관심이 있거나(변경 사항을 전파하지 않음), 민간 개발(원래 프로젝트에 다시 기여하지 않음)에 관심이 있거나, 해외 프로젝트를 자신의 프로젝트의 기반으로 사용하는 경우(변경 사항은 현지적이며 게시하는 것이 타당하지 않음).

Git는 사용자 지정 효율적인 방법을 통해 익명으로 인증되지 않은 읽기 전용 액세스를 지원합니다.git://프로토콜, 또는 방화벽 차단의 배후에 있는 경우DEFAULT_GIT_PORT(9418) 일반 HTTP를 사용할 수 있습니다.

CVS의 경우 읽기 전용 액세스를 위한 가장 일반적인 솔루션은 'pserver' 프로토콜에 대한 게스트 계정입니다.CVS_AUTH_PORT(2401), 보통 "anonymous"라고 불리며 빈 비밀번호를 사용합니다.자격 증명은 기본적으로 에 저장됩니다.$HOME/.cvspass파일이라 한 번만 제공해야 하지만, 이것은 약간의 장벽(게스트 계정의 이름을 알아야 하거나, CVS 서버 메시지에 주의해야 함)과 귀찮음이 있습니다.

• 프린지 디벨로퍼(리프 기여자).OSS의 변경 사항을 전파하는 한 가지 방법은 이메일을 통해 패치를 전송하는 것입니다.이것은 우발적인 개발자이거나, 단일 변경 또는 단일 버그 수정을 보낸 경우 가장 일반적인 해결책입니다. BTW. 패치를 보내는 것은 이메일뿐만 아니라 리뷰 보드(패치 리뷰 시스템) 또는 유사한 수단을 통해 할 수 있습니다.

Git는 발신자(클라이언트)와 유지 관리자(서버) 모두에게 이 전파(퍼블리싱) 메커니즘에 도움이 되는 도구를 제공합니다.이메일을 통해 변경사항을 발송하려는 사람들을 위해 현재 업스트림 버전 위에 사용자 자신의 변경사항을 재생하는 "git rebase"(또는 "git pull --rebase") 도구가 있으므로 변경사항은 현재 버전 위에 있고(새로 작성), 커밋 메시지(및 작성자 권한)가 있는 이메일을 작성하는 "git format-patch" 도구가 있습니다.(extended) Unified diff 형식으로 변경합니다(게다가 diffstat를 추가하여 검토를 쉽게 함).유지 관리자는 이러한 이메일을 직접 "gitam"을 사용하여 모든 정보(커밋 메시지 포함)를 커밋 보존으로 전환할 수 있습니다.

CVS는 그런 도구를 제공하지 않습니다. "cvs diff" / "cvs rdiff"를 사용하여 변경 사항을 생성하고 GNU 패치를 사용하여 변경 사항을 적용할 수 있지만 커밋 메시지 적용을 자동화하는 방법은 없는 것으로 알고 있습니다.CVS는 클라이언트 <-> 서버 패션에 사용될 예정이었습니다...

• 중위의프로젝트의 별도 부분(하위 시스템)을 관리하거나 프로젝트의 개발이 Linux 커널 개발에 사용되는 "신뢰 네트워크" 워크플로우를 따르는 경우...또는 자신의 공용 저장소가 있고 게시하려는 변경 사항이 너무 커서 이메일을 통해 패치 시리즈로 보낼 수 없는 경우 프로젝트의 (메인) 유지 관리자에게 풀 요청을 보낼 수 있습니다.

이 솔루션은 분산 버전 제어 시스템에 고유한 솔루션이므로 물론 CVS는 이러한 방식의 협업을 지원하지 않습니다.심지어 "git request-pull"이라고 불리는 도구도 있는데, 이 도구는 저장소에서 꺼내기 요청과 함께 관리자에게 보낼 이메일을 준비하는 데 도움이 됩니다."깃 번들" 덕분에 이메일이나 스니커넷을 통해 변경 번들을 전송함으로써 공용 저장소가 없어도 이 메커니즘을 사용할 수 있습니다.GitHub와 같은 일부 Git 호스팅 사이트는 누군가가 당신의 프로젝트에서 일하고 있다는 것을 알리거나(만약 그/그녀가 같은 Git 호스팅 사이트를 사용한다면), 일종의 pull 요청을 PM-ing하는 것을 지원합니다.

• 주 개발자, 즉 자신의 변경 사항(주/canonical 저장소)을 직접 게시하는 사람.중앙 저장소에 대한 쓰기 액세스 권한을 가진 여러 개발자를 보유하는 것은 워크플로우뿐만 아니라 분산 버전 제어 시스템의 경우에도 이 범주가 더 넓습니다(표준 저장소에 대한 변경 사항을 적용하는 단일 유지 관리자, 해당 유지 관리자가 참여하는 일련의 중위/하위 시스템 유지 관리자 및 광범위한 리프 개발자를 보유할 수 있음).관리자/프로젝트 메일링 리스트 또는 중위/하위 관리자 중 한 명에게 우편으로 패치를 전송합니다.

Git를 사용하면 SSH 프로토콜(SSH로 래핑된 git 프로토콜)을 사용하여 변경 사항을 게시할 수 있습니다. "git shell"(보안을 지원하여 셸 계정의 액세스를 제한) 또는 Gitosis(별도의 셸 계정 없이 액세스를 관리하는) 도구와 일반 HTTP 인증을 사용하여 WebDAV로 HTTPS를 사용할 수 있습니다.

CVS의 경우 사용자 지정 암호화되지 않은(일반 텍스트) pserver 프로토콜을 사용하거나 원격 셸(SSH를 실제로 사용해야 하는 곳)을 사용하여 변경 사항을 게시할 수 있습니다. 중앙 집중화된 버전 제어 시스템의 경우 변경 사항을 커밋(커밋 생성)하는 것을 의미합니다.SSH를 사용하여 'pserver' 프로토콜을 터널링할 수도 있고, 이를 자동화하는 제3의 도구도 있습니다.하지만 난 이게 예를 들어 그렇게 쉬운 일은 아니라고 생각합니다.기토시스.

Git와 같은 일반적인 분산 버전 제어 시스템은 가능한 워크플로우를 훨씬 더 폭넓게 선택할 수 있습니다.CVS와 같은 중앙 집중형 버전 제어 시스템을 사용하면 저장소에 대한 커밋 액세스 권한을 가진 사람과 없는 사람을 구별해야 합니다.그리고 CVS는 (패치를 통해) 커밋 액세스 없이 사람들로부터 기부금을 받는 데 도움이 되는 어떠한 도구도 제공하지 않습니다.

Karl Fogel은 오픈 소스 소프트웨어 제작에서 버전 제어에 관한 부분에서 너무 엄격하게 제공하지 않는 것이 좋다고 언급하고 있습니다.공용 저장소를 변경할 수 있는 영역에 대한 엄격하고 엄격한 통제. 기술적 제한보다는 사회적 제한(코드 검토 등)에 의존하는 것이 훨씬 낫습니다. 분산 버전 제어 시스템은 IMHO를 더욱 감소시킵니다.

Git 웹사이트는 아마도 이것을 가장 잘 설명합니다.

제 애완동물의 특징은 오프라인에서 커밋을 할 수 있는 것입니다.속도, 밀거나 당기는 것을 제외한 모든 것이 일어나는 엄청난 속도입니다. (이러한 작업은 설계상 비파괴적이기 때문에 중앙 레포가 뒤떨어지면 커피를 마시러 갈 때 밀거나 당길 수 있습니다.또 다른 좋은 점은 배터리가 포함되어 있다는 것입니다: 내장형gitk충분히 좋은 역사 시청자입니다.git gui커밋 도구로 충분합니다. 출력 컬러화로,git add -i,git add -p,git rebase -i대화형 인터페이스가 충분합니다.git daemon그리고.git instaweb중앙 레포를 만지작거리고 싶지 않다면 임시 공동 작업을 수행하기에 충분합니다.

CVS가 중앙 집중형인 것과 달리 Git는 DVCS입니다.간단히 설명하자면, 여러 저장소에 연결되지 않았을 때 버전 제어의 모든 이점을 얻을 수 있고, 작업 속도도 빨라집니다.

저는 또한 cvs를 10년 이상 사용하는 가장 행복한 사용자이지만, 비록 제가 현재 작업하는 대부분의 프로젝트는 cvs 또는 svn을 사용하지만, 우리는 방화벽을 통해 git-hole을 뚫도록 설득하는 관료주의를 얻을 수 없는 것 같습니다.

cvs를 다른 것보다 더 좋게 만드는 몇 가지는 cvsps이고, 또 다른 것은 앤드류 모튼의 패치 스크립트나 퀼트입니다.Cvsps를 사용하면 커밋의 여러 파일을 하나의 패치로 재구성할 수 있고(따라서 CVS에서 "변경 세트"를 추출할 수 있습니다), 또는 앤드류 모튼의 패치 스크립트를 사용하면 합리적인 "변경 세트"를 CVS로 쉽고 편하게 커밋할 수 있습니다.작업을 수행하기 전에 분리된 상태를 유지하면서 동시에 여러 가지 작업을 수행할 수 있습니다.CVS는 특이한 점이 있지만 대부분 익숙합니다.

"x년 이상 CVS를 행복하게 사용한다"는 흥미로운 아이디어입니다 :-) 많은 복사본을 보관하는 것에서 크게 향상된 것이지만...

당신은 모든 별난 것들에 익숙해졌거나, 아니면 분기나 합병을 많이 하지 않는 것 같습니다.더 나쁜 가능성이 있습니다.

귀사의 직원들은 cvs 제한에 익숙해져 있으며 업무 관행도 그에 따라 적응하고 있습니다.

예를 들어, 한 번에 하나 이상의 개발자가 하나의 패키지에 대해 작업을 수행하지 않는 경우, 비상 상황에서만 분기 작업을 수행하는 경우 등입니다.

기본 원칙은 어려운 일일수록 사람들이 덜 한다는 것입니다.

언급URL : https://stackoverflow.com/questions/802573/difference-between-git-and-cvs