GIT와 CVS의 차이

Question

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

나는 10 년 넘게 CVS를 행복하게 사용해 왔으며 이제는 git이 훨씬 나아 졌다고 들었습니다. 누군가 두 사람의 차이점이 무엇인지, 왜 하나가 다른 것보다 더 나은지 설명해 주시겠습니까?

Answer 1

주요 차이점은 (이미 다른 응답에서 이미 언급 된 바와 같이) CVS는 (이전) 중앙 집중식 버전 제어 시스템이고 GIT가 배포된다는 것입니다.

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

• 저장소 설정. git 저장소 저장소 .git 프로젝트의 상단 디렉토리의 디렉토리; CVS는 다른 프로젝트 (모듈)에 대한 버전 제어 정보를 저장하기위한 중심 위치 인 CVSROOT를 설정해야합니다. 사용자를위한 해당 설계의 결과는 기존 소스를 버전 제어로 가져 오는 것이 "git init && git add. && git commit"만큼 간단하다는 것입니다. 더 복잡한 CVS에서.

• 원자 연산. 처음에 CV는 파일당 RCS 버전 제어 시스템 주변의 스크립트 세트 였기 때문에 CVS에서 Commits (및 기타 작업)는 원자가 아닙니다. 저장소에서의 작업이 중간에 중단되면 저장소는 일관되지 않은 상태로 남겨질 수 있습니다. GIT에서 모든 작업은 원자입니다. 전체적으로 성공하거나 변경없이 실패합니다.

• 변경 사항. CV의 변경 사항은 파일 당이며 GIT의 변경 (커밋)은 항상 전체 프로젝트를 참조합니다. 이건 매우 중요합니다 패러다임 변화. 이것의 결과 중 하나는 git에서 되돌리기가 매우 쉽다는 것입니다 (취소하는 변경을 만들어) 또는 실행 취소 전부의 변화; 다른 결과는 CV에서 부분 체크 아웃을 쉽게 수행 할 수 있지만 현재 GIT에서 불가능한 옆에 있습니다. 변경 사항이 파일 당이며 그룹화 된 사실은 CVS의 커밋 메시지를위한 GNU ChangeLog 형식의 발명으로 이어졌습니다. GIT 사용자는 다른 컨벤션을 사용 (및 일부 GIT 도구를 기대) 한 줄을 설명하고 (요약) 변경 한 다음 빈 라인을 설명하고 변경 사항에 대한 자세한 설명이 이어집니다.

• 이름 지정 개정 / 버전 번호. CVS에서 변경 사항이 파일 당 : 버전 번호 (때때로 볼 수 있듯이 키워드 확장, 아래 참조) 1.4는 주어진 파일이 얼마나 많은 시간을 변경했는지를 반영합니다. GIT에서 각 버전의 프로젝트 전체 (각 커밋)는 SHA-1 ID가 제공 한 고유 한 이름을 가지고 있습니다. 일반적으로 첫 번째 7-8자는 커밋을 식별하기에 충분합니다 (중앙 번호 매기기 권한이 필요한 분산 버전 제어 시스템의 버전에 간단한 번호 체계를 사용할 수 없습니다). CVS에서 버전 번호 또는 상징적 이름이있는 프로젝트 상태를 전체적으로 언급합니다. 태그; 프로젝트의 일부 버전에서 'v1.5.6-rc2'와 같은 이름을 사용하려면 git에서도 마찬가지입니다. 그러나 Git의 태그는 사용하기가 훨씬 쉽습니다.

• 쉬운 분기. CV의 지점은 제 생각에 지나치게 복잡하고 다루기가 어렵습니다. 전체 저장소 지점의 이름을 갖도록 지점에 태그를 붙여야합니다 (그리고 파일 당 처리로 인해 올바르게 기억하면 경우에도 실패 할 수 있습니다). CVS에는 없다는 사실을 추가하십시오 병합 추적, 따라서 합쳐 지점과 분기점을 기억하거나 수동으로 태그하고 "CVS Update -J"에 대한 올바른 정보를 수동으로 제공하여 분기를 병합해야하며 분기가 불필요하게 사용하기 어려운 경우가 있습니다. git에서 분기를 만들고 병합하는 것은 매우 쉽습니다. git은 필요한 모든 정보 자체를 기억합니다 (따라서 지점을 병합하는 것은 쉬운 일입니다. 지점명") ... 분산 개발이 자연스럽게 여러 개의 지점으로 이어지기 때문에해야했습니다.

  이것은 당신이 사용할 수 있음을 의미합니다 주제 지점, 즉 별도의 기능 분기에서 여러 단계에서 별도의 기능을 개발합니다.

• 이름 바꾸기 (및 복사) 추적. 파일 이름 바꾸기는 CVS에서 지원되지 않으며 수동 이름 변경은 2 개로 기록을 깨뜨 리거나 이름을 바꾸기 전에 프로젝트 상태를 올바르게 복구 할 수없는 유효하지 않은 기록으로 이어질 수 있습니다. GIT는 내용과 파일 이름의 유사성을 기반으로 휴리스틱 라이 이름 탐지를 사용합니다 (이 솔루션은 실제로 잘 작동합니다). 파일 복사 감지를 요청할 수도 있습니다. 이것은 다음을 의미합니다.

  • 지정된 커밋을 검사 할 때 일부 파일이 이름이 바뀌는 정보를 얻을 수 있습니다.
  • 올바르게 인식을 고려합니다 (예 : 파일의 이름이 한 분기에만 바뀌었던 경우).
  • 파일 내용의 라인 별 기록을 보여주는 도구 인 "CVS Annotate"와 동등한 (더 나은) 인 "Git Blame"은 이름을 통해 코드 이동을 따라갈 수 있습니다.

• 이진 파일. CVS는 바이너리 파일 (예 : 이미지)에 대한 매우 제한된 지원 만하며, 사용자는 "CVS Admin"을 추가 할 때 (또는 나중에 "CVS Admin"을 사용하거나 랩퍼를 통해 파일 이름을 기준으로 해당 작업을 수행 할 때 이진 파일을 명시 적으로 표시해야합니다. 종말 전환 및 키워드 확장을 통한 이진 파일. GIT는 CNU Diff 및 기타 도구가 수행하는 것과 같은 방식으로 내용을 기반으로 이진 파일을 자동으로 감지합니다. gitattributes 메커니즘을 사용 하여이 탐지를 무시할 수 있습니다. 또한 바이너리 파일은 'SafeCRLF'에 대한 기본값 (및 배포에 따라 기본적으로 켜져있을 수 있지만) 및 해당 (제한) 키워드에 대한 기본값 덕분에 반복 할 수없는 망글 링에 안전합니다. 확장은 git에서 엄격한 '옵트 인'입니다.

• 키워드 확장. GIT는 CVS (기본적으로)에 비해 매우 제한된 키워드 세트를 제공합니다. 이는 두 가지 사실 때문입니다. GIT의 변경 사항은 리포지토리 당이며 파일 당이 아니며 GIT는 다른 지점으로 전환 할 때 변경되지 않은 파일을 수정하거나 다른 지점으로 되감기를 수정하지 않습니다. GIT를 사용하여 개정 번호를 포함 시키려면 빌드 시스템을 사용하여이를 수행해야합니다. 예를 들어 Linux 커널 소스 및 GIT 소스의 GIT-Version-Gen 스크립트의 예를 사용하십시오.

• 수정은 커밋됩니다. Git Act와 같은 분산 VC에서 출판 커밋을 만드는 것과 분리되어 있으며 다른 사용자를 불편하게하지 않고 출판되지 않은 역사를 변경 (편집, 재 작성) 할 수 있습니다. 특히 커밋 메시지에 오타 (또는 기타 오류)가 표시되거나 Commit의 버그가있는 경우 "Git Commit -Amend"를 사용하면 간단히 사용할 수 있습니다. 이것은 CVS에서 불가능하다 (적어도 무거운 해커가 없음).

• 더 많은 도구. GIT는 CV보다 훨씬 더 많은 도구를 제공합니다. 더 중요한 것 중 하나는 "git bisect"버그를 도입 한 커밋 (개정)을 찾는 데 사용될 수 있습니다. 커밋이 작고 자 급식이라면 버그가 어디에 있는지 알아 내기가 매우 쉬워야합니다.

---

최소한 한 명의 다른 개발자와 협력하는 경우 GIT와 CVS의 다음 차이점도 있습니다.

• 병합 전에 커밋하십시오 git 사용 커밋 전의 커밋 CV와 같은 것보다 커미트 전 병합 (또는 업데이트-커밋). 파일을 편집하는 동안 새로운 커밋을 만들기 위해 준비한 경우 (새로운 개정) 다른 사람이 같은 지점에서 새로운 커밋을 만들었으며 이제 저장소에 있습니다. CVS는 먼저 작업 디렉토리를 업데이트하고 충돌을 해결하기 전에 충돌을 해결해야합니다. 이것은 git의 경우가 아닙니다. 먼저 버전 제어에 상태를 저장 한 다음 다른 개발자 변경 사항을 병합합니다. 다른 개발자에게 병합을 수행하고 갈등을 해결하도록 요청할 수도 있습니다.

  선형 이력을 선호하고 합병을 피하려면 언제든지 사용할 수 있습니다. Commit-Merge-Recommit "git rebase"(및 "git pull -rebase")를 통한 워크 플로우는 업데이트 된 상태 위에 변경 사항을 재생한다는 점에서 CVS와 유사합니다. 그러나 당신은 항상 먼저 커밋합니다.

• 중앙 저장소가 필요하지 않습니다 git을 사용하면 변경 사항을 저지르는 단일 중앙 장소가 필요하지 않습니다. 각 개발자는 자체 리포지토리 (또는 더 나은 저장소 : 개발을 수행하는 개인 저장소 및 준비된 부분을 게시하는 공개 저장소를 가질 수 있습니다. 대칭 패션. 반면에 더 큰 프로젝트가 사회적으로 모든 사람이 가져 오는 정의/지명 중앙 저장소.

---

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

• 루커. 프로젝트에서 최신 변경 사항을 얻는 데 관심이있는 경우 (변화에 대한 전파가 없습니다) 또는 행동 사적인 개발 (원래 프로젝트에 대한 기여없이); 또는 외국 프로젝트를 자신의 프로젝트의 기초로 사용합니다 (변경 사항은 로컬이며 게시하는 것이 합리적이지 않습니다).

  GIT가 여기에서 지원합니다 익명의 무단 사용자 정의 효율을 통한 읽기 전용 액세스 git://프로토콜 또는 방화벽 차단 뒤에있는 경우 DEFAULT_GIT_PORT (9418) 일반 HTTP를 사용할 수 있습니다.

  CVS의 경우 가장 일반적인 솔루션 (이해대로 읽기 전용 액세스)은 다음과 같습니다. 게스트 계정 'PSERVER'프로토콜 켜기 CVS_AUTH_PORT (2401), 일반적으로 "익명"이라고하며 빈 비밀번호가 있습니다. 자격 증명은 기본적으로 저장됩니다 $HOME/.cvspass 파일, 따라서 한 번만 제공해야합니다. 그럼에도 불구하고 이것은 약간의 장벽 (게스트 계정 이름을 알고 CVS 서버 메시지에주의를 기울여야 함)과 성가심입니다.

• 프린지 개발자 (잎 기고자). OSS의 변화를 전파하는 한 가지 방법은입니다 이메일을 통해 패치를 보냅니다. 이는 우발적 인 개발자, 단일 변경 또는 단일 버그 수정을 보내는 경우 가장 일반적인 솔루션입니다. BTW. 패치를 보내는 것은 이메일을 통해서뿐만 아니라 리뷰 보드 (패치 검토 시스템) 또는 유사한 수단 일 수 있습니다.

  GIT는 여기에서 발신자 (클라이언트) 및 관리자 (서버)를위한 이러한 전파 (게시) 메커니즘에 도움이되는 도구를 제공합니다. 이메일을 통해 변경 사항을 보내려는 사람들은 "git rebase"(또는"git pull -rebase ") 도구는 현재 업스트림 버전 위에 자신의 변경 사항을 재생할 수 있도록하여 변경 사항이 현재 버전 (신선) 및"및 "및"및 "및"및 "및"및 "및"변경 사항은 "신선하고". "git 형식 패치"커밋 메시지 (및 저자)가있는 이메일을 만들려면 (확장 된) 통합 Diff 형식 (더 쉽게 검토를위한 Diffstat) 형식으로 변경됩니다. 관리자는 이러한 이메일을 모든 정보 (커밋 메시지 포함) 사용으로 직접 전환 할 수 있습니다."git am".

  CVS는 그러한 도구를 제공하지 않습니다. "CVS Diff" / "CVS RDIFF"를 사용하여 변경 사항을 생성하고 GNU 패치를 사용하여 변경 사항을 적용 할 수 있지만, 아는 한 커밋 메시지 적용을 자동화 할 수있는 방법이 없습니다. CVS는 클라이언트 <-> 서버 패션에서 사용되기위한 것입니다 ...

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

  이것은 특정 솔루션입니다 배포 버전 제어 시스템이므로 물론 CVS는 그러한 협업 방식을 지원하지 않습니다. "git request-pull"이라는 도구도 있습니다.이 도구는 저장소에서 가져 오라는 요청을 통해 관리자에게 보내기 위해 이메일을 준비하는 데 도움이됩니다. "Git Bundle"덕분에 이메일이나 운동성을 통해 변경 묶음을 보내서 공개 저장소가 없어도이 메커니즘을 사용할 수 있습니다. GIT 호스팅 사이트 중 일부 github 누군가가 프로젝트 (동일한 GIT 호스팅 사이트를 사용하는 경우)에서 일하고 (일부 작업을 게시 함), PM-ing에 대한 일종의 풀 요청을 알리는 것을 지원하십시오.

• 주요 개발자, 즉 누군가 직접 게시합니다 그/그녀의 변화 (주/표준 저장소로). 이 범주는 분산 버전 제어 시스템의 경우 더 넓습니다. 중앙 저장소에 대한 쓰기에 액세스 할 수있는 여러 개발자가 가능한 워크 플로 일뿐 만 아니라 푸시 정식 저장소, 자신이 당기는 중위/서브 시스템 관리자 세트 및 Mailseer/Project Mailing List 또는 중위/하위 메인 참고 자 중 한 명에게 메일을 통해 패치를 보내는 광범위한 잎 개발자의 변경).

  git을 사용하면 사용을 선택할 수 있습니다 SSH 프로토콜 (SSH로 랩핑 된 GIT 프로토콜) "Git Shell"과 같은 도구 (보안을 돕기 위해 쉘 계정의 액세스 제한) 또는 기티술 (별도의 쉘 계정이 필요하지 않고 액세스를 관리하려면) HTTPS Webdav와 함께 일반적인 HTTP 인증이 있습니다.

  CV는 커스텀 중에서 선택할 수 있습니다 암호화되지 않은 (일반 텍스트) PSERVER 프로토콜 또는 사용 원격 쉘 (실제로 사용해야합니다 SSH) 변경 사항을 게시합니다 중앙 집중식 버전 제어 시스템은 변경 사항을 커밋하는 (커밋 생성)를 의미합니다. 글쎄, 당신은 또한 SSH를 사용하여 'Pserver'프로토콜을 터널 할 수 있으며, 이것을 자동화하는 3 개의 파티 도구가 있습니다 ... 그러나 나는 이것이 예를 들어 Gitosis만큼 쉽지 않다고 생각합니다.

GIT와 같은 일반적인 분산 버전 제어 시스템은 가능한 더 많은 워크 플로를 제공합니다. CVS와 같은 중앙 집중식 버전 제어 시스템을 사용하면 필연적으로 저장소에 액세스 할 수있는 사람들을 구별해야합니다. 액세스를 커밋하십시오.

Karl Fogel 오픈 소스 소프트웨어 생성 버전 제어에 대한 섹션에서 공개 저장소를 변경할 수있는 영역에서 너무 엄격하고 단단하며 엄격한 제어를 제공하지 않는 것이 좋습니다. 기술 제한보다 사회적 제한 (예 : 코드 검토)에 의존하는 것이 훨씬 낫습니다. 분산 버전 제어 시스템은 IMHO를 더욱 줄입니다 ...

HTH (도움이되기를 바랍니다)

Answer 2

git은 a DVC, CV가 중앙 집중식과는 반대로. 단순한 설명은 다음과 같습니다. 연결되지 않은 경우 버전 제어의 모든 이점을 얻습니다. 어느 가능한 여러 저장소의 경우 작업이 더 빠릅니다.

Answer 3

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

내 애완 동물 기능은 오프라인에서 커밋 할 수 있습니다. 그리고 속도, 밀고 당기는 것을 제외한 모든 것이 발생하는 깎아 지른 속도. (그리고이 작업은 디자인 비파괴로 이루어 지므로 중앙 레포가 지연되면 커피를 잡을 때 밀거나 당길 수 있습니다.) 또 다른 좋은 점은 배터리가 포함되어 있다는 것입니다. gitk 충분히 좋은 역사 시청자입니다. git gui 충분한 커밋 도구입니다. 출력 색상화로 git add -i, git add -p, git rebase -i 충분한 대화식 인터페이스입니다. git daemon 그리고 git instaweb 중앙 리포와 함께 바이올린을 원하지 않는 경우 임시 협업에 충분합니다.

Answer 4

나는 또한 10 년 이상의 CVS 사용자이지만 GIT도 좋아하지만 시간이 지남에 따라 선호하는 대부분의 프로젝트는 현재 CVS 또는 SVN을 사용하고 있지만 우리는 보이지 않을 것입니다. 내가 일하는 곳의 관료주의를 얻으려면 방화벽을 통해 git 구멍을 뚫을 것이라고 확신했습니다.

CVS가 그렇지 않으면 CVS를 더 멋지게 만드는 몇 가지는 CVSP이며 다른 하나는 Andrew Morton의 패치 스크립트 또는 이불입니다. CVSPS는 Quilt 또는 Andrew Morton의 패치 스크립트를 통해 CVS의 여러 파일을 단일 패치 (따라서 CVS에서 "변경 사항을 추출 함)로 재구성 할 수 있습니다. 헌신하기 전에 여전히 분리 된 상태로 유지하면서 동시에 일을 동시에 작업하십시오. CVS에는 단점이 있지만 대부분의 사람들에게 익숙합니다.

Answer 5

"행복하게 X 년 동안 CV를 사용하는 것"은 흥미로운 아이디어입니다 :-) 그것은 많은 사본을 보관하는 데 큰 발걸음이지만 ...

나는 당신이 모든 것을 무시하거나 분기와 병합을 많이하지 않는다고 생각합니다. 더 나쁜 가능성이 있습니다.

조직의 사람들은 CVS 제한에 익숙해졌으며 귀하의 업무 관행은 그에 따라 적응했습니다.

예를 들어, 한 번에 하나의 패키지에서 하나 이상의 개발자가 작업하지 않으며 응급 상황에서 분기를 사용하는 것만으로 만 사용하지 않습니다.

기본 원칙은 더 어려울수록 사람들이 더 적게하는 것입니다.