github 는 2008 년에 시작되었습니다. 내 것과 같은 소프트웨어 엔지니어링 경력이 Github 보다 오래 되었다면 Git 은 지금까지 사용 된 유일한 버전 제어 소프트웨어 일 수 있습니다. 면서 사람들은 때때로 그라우스에 대해 그것의 가파른 학습 곡선 orunintuitive 인터페이스,자식은 모두가 이 버전이 제어합니다. InStack Overflow 의 2015 개발자 설문 조사에서 응답자의 69.3%가 Git 을 사용했으며 거의 두 번째로 많이 사용되는 버전 제어 시스템 인 Subversion 을 사용했습니다.1 2015 년 이후에,Stack Overflow 정지 요구는 개발자에 대한 theversion 제어 시스템을 사용하기 때문에,아마 Git 가 popularthat 질문이 재미있다.Git 자체는 Github 보다 훨씬 오래되지 않았습니다. Linus Torvalds 는 첫 번째를 발표했습니다.2005 년 Git 버전. 하지만 오늘날 젊은 개발자들이 힘든 timeconceiving 세계의 용어”버전 제어 소프트웨어”지 않았다 더 orless 의미 Git,이러한 세계에 존재하는지 너무 오래 전에. 선택할 수있는 옵션이 많이있었습니다. 오픈 소스 개발자가 선호하는 파괴,기업 비디오 게임 회사는 사용들(일부는 여전히),동 theLinux 커널은 프로젝트명에 의존 버전 관리 시스템 calledBitKeeper.
이러한 시스템 중 일부,특히 BitKeeper 는 시간을 거슬러 올라간 youngGit 사용자에게 친숙하다고 느낄 수 있습니다. 대부분은하지 않을 것입니다. BitKeeper 는 제쳐두고,버전 Git 전에 온 제어 시스템은 근본적으로 다른 패러다임에 따라 작동했습니다. 에서 분류를 제공하여 에릭 싱크대,저자의 VersionControl 예를 들어,Git 가전 제어 시스템,whilemost 의 Git 전 시스템 인기 있는 1990 년대와 2000 년대 초반에는 두 번째 세대의 버전 관리 시스템입니다.2 제 3 세대 버전 제어 시스템이 배포되는 곳,2 세대 버전 제어 시스템이 중앙 집중화됩니다. 이전에 Git 이”분산 된”버전 제어 시스템으로 설명했다고 거의 확실하게 들었습니다. 나는 적어도 중앙 집중식 2 세대 버전 제어 시스템을 설치하기 전까지는 distributed/centrated 구분을 이해하지 못했습니다.내가 설치 한 시스템은 CVS 였습니다. 동시 버전 시스템의 줄임말 인 CVS 는최초 2 세대 버전 제어 시스템. 그것은 또한 2000 년에 대체 될 때까지 약 10 년 동안 가장 인기있는 버전 제어 시스템이었습니다.전복. 그때조차도,Subversion 은”CVS 하지만 더 나은”것으로 가정되었는데,이는 1990 년대 내내 cvs 가 얼마나 지배적 이었는지를 강조합니다.
CVS 처음 개발되었에 의해 1986 년에 네덜란드 컴퓨터 과학자로 이름 딕 옵션에는 날마를 찾고 있었는 방법과 협력하는 그의 학생들에 compilerproject.3CVS 는 처음에는 Grune 이 개선하기를 원했던 1 세대 버전 제어 시스템 인 shell scriptswrapping RCS(Revision Control System)의 모음보다 조금 더 많았습니다. RCS 는 비관적 인 locking 모델에 따라 작동하므로 두 명의 프로그래머가 단일 파일 atonce 에서 작업 할 수 없음을 의미합니다. 파일을 편집하기 위해,당신은 먼저 독점 lockon 파일에 대한 RCS 를 요청해야,당신이 편집을 완료 할 때까지 유지하는. 다른 사람이이미 편집해야하는 파일을 편집하면 기다려야합니다. CVS 개선에 RCSand 안내에서 두 번째 세대의 버전 관리 시스템에 의해 거래 thepessimistic 잠그는 모델에 대한 낙관적인 하나입니다. 프로그래머는 이제 동시에 thesame 파일을 편집하여 편집 내용을 병합하고 충돌을 해결할 수 있습니다. (나중에 cvs 프로젝트를 인수 한 엔지니어 인 Brian Berliner 는 1990 년 cvs 의 혁신에 대해 매우 읽기 쉬운 paperabout 을 wrotea.)
그런 의미에서 CVS 는 낙관적 인 모델에 따라 작동하는 Git 과 모두 다르지 않았습니다. 그러나 그것이 유사점이 끝나는 곳입니다. Infact,Linus Torvalds 가 Git 을 개발하고있을 때,그의 지침 원칙 중 하나는 wwcvsnd 또는”CVS 가하지 않을 것”이었습니다.”그가 결정에 대해 의심 스러울 때마다,그는 디자인 ofCVS 에서 선택되지 않은 옵션을 선택하려고 노력했습니다.4 따라서 CVS 가 10 년 이상 Git 을 앞질렀음에도 불구하고 Git asa 종류의 부정적인 템플릿에 영향을 미쳤습니다.
나는 CVS 와 함께 노는 것을 정말로 즐겼습니다. 나는 Git 의 분산 된 성격이 왜 그런 camebefore 에 대한 개선인지 이해하는 더 좋은 방법이 없다고 생각합니다. 그래서 나는 당신을 초대해 함께 와서 나와 함께 흥미 진진한 여행을 andspend 다음의 십분의 생활에 대해 학습의 조각 softwarenobody 가에 사용되는 마지막 십년간. (보정을 참조하십시오.)
CVS 시작하기
cvs 설치 지침은 project’shomepage 에서 찾을 수 있습니다. MacOS 에서는 다음을 사용하여 CVS 를 설치할 수 있습니다.homebrew.
CVS 가 중앙 집중화되어 있기 때문에 Git 과 같은 것이없는 방식으로 클라이언트 측 유니버스 와 서버 측 유니버스를 구별합니다. Thedistinction 은 다른 실행 파일이 있다는 것을 그렇게 발음하지 않습니다. 그러나 cvs 사용을 시작하려면 자신의 컴퓨터에서도 theCVS 백엔드를 설정해야합니다.
모든 코드의 중앙 저장소 인 CVS 백엔드를 저장소라고합니다.Git 에서는 일반적으로 모든 프로젝트에 대한 저장소를 갖지만 CVSthe 저장소는 모든 프로젝트를 보유합니다. 한 번에 프로젝트 만 작업 할 수있는 방법이 있지만 하나의 중앙 저장소가 있습니다.
로컬 저장소를 만들려면init명령을 실행합니다. 당신은 이것을 할 것입니다.홈 디렉토리처럼 글로벌.
$ cvs -d ~/sandbox initCVS 전달할 수 있습니션cvsinitcvs명령 뒤에 나타나는 옵션은 전역 innature 이며 하위 명령 뒤에 나타나는 옵션은 thesubcommand 에 따라 다릅니다. 이 경우-d플래그는 글로벌입니다. 여기에서 발생하는 말 CVSwhere 우리가 만들려고 하는 우리의 저장소하지만,일반적으로-d플래그 포인트 니 저장소 위치는 우리가 사용하려면 어떤 주어진다. 할 수 있습 betedious 을 공급-dCVSROOTenvironmentvariable 설정할 수 있다.
이후 우리는 작업 로컬로,우리는 그냥 전달 경로에 대한 우리의-d인수,그러나 우리는 또한 포함하는 호스트 이름이 있습니다.
명령은 홈 디렉토리에sandboxsandboxCVSROOT라는 다른 directorycalled 가 포함되어 있음을 알 수 있습니다. 이 디렉토리는 환경과 혼동하지 않으려면가변성,저장소에 대한 관리 파일을 보유합니다.
축하합니다! 방금 첫 번째 CVS 저장소를 만들었습니다.
코드 체크인
좋아하는 색상의 목록을 유지하기로 결정했다고 가정 해 봅시다. 너는예술적으로 기울어 지지만 극도로 건망증이있는 사람. 당신은 유형의 목록 색상과 파일로 저장이라는favorites.txt
blueorangegreendefinitely not yellow자는 또한 가정을 저장하는 파일에서 새로운 디렉터리colors. 지금 당신을 넣어 좋아 좋아하는 컬러 목록에서 버전을 제어하기 때문에,오십년에서 지금 보는 흥미로운 일이 될 것이 다시 howyour 맛이 변경되었을 통해 시간.그렇게하려면 디렉토리를 새 CVSproject 로 가져와야합니다. import명령을 사용하여 수행 할 수 있습니다:
$ cvs -d ~/sandbox import -m "" colors colors initialN colors/favorites.txtNo conflicts created by this import여기서 우리는 우리의 위치를 지정하는 우리의 가장-dflagagain. 나머지 인수는importcolors는 저장소에 새 디렉토리의 이름을 지정합니다.마지막 두 인수는 공급 업체 태그와 릴리스 태그를 각각 지정합니다.우리는 1 분 안에 태그에 대해 더 이야기 할 것입니다.
방금”colors”프로젝트를 CVS 저장소로 가져 왔습니다. 가 있 acouple 다른 방법에 대해 이동하는 데 코드로 CVS,하지만 이것은 themethod 추천에 의해 실용적인 버전 관 UsingCVS,the PragmaticProgrammer 에 대한 책 CVS. 이 방법은 좀 어색한 것은 youthen 확인해야하는 작업이 신선하더라도,당신은 이미 사용하여 기존colors디렉토리에 있습니다. 그 디렉토리를 사용하는 대신에는그것을 선택한 다음 CVS 가 이미 알고있는 버전을 확인하십시오:
$ cvs -d ~/sandbox co colorscvs checkout: Updating colorsU colors/favorites.txt이것은 새로운 디렉토리를 생성,또한colorsfavorites.txtCVSCVS디렉토리는 기본적으로 CVS’해당하는.gitdirectoryin 모든 Git 장합니다.
변경 만들기
여행 준비.
처럼 Git,CVS 는status하위 명령:
이것은 일을 시작하 보면 외국인이다. CVS 에는 커밋 개체가 없습니다. 에 위라는 뭔가가있”Commit 식별자,”하지만 이것 beonly 비교적 최근 버전의 언급”Commit 식별자는”나타납 inPragmatic 버전을 사용하여 제어 CVS,는 2003 년에 출판되었다. (이 lastupdate 을 CVS 에 출시되었 2008.5)
반면 Git 당신에 대해 이야기 버전의 파일과 관련된 commit45de392에서 CVS 파일 버전 관리되는 따로 있습니다. Yourfile 의 첫 번째 버전은 버전 1.1,다음 버전은 1.2 등입니다. 면 지점 areinvolved,여분의 숫자 추가됩니다,그래서 당신은 끝낼 수 있습니다 뭔가가 나옵1.1.1.1위에 나타나는 기본값으로 우리의 경우에도 wehaven 없 만든 가지입니다.
을 실행한다면cvs loggit log)프로젝트에서 lotsof 파일과 커밋을 개인이 역사에 대한 각각의 파일입니다. 버전 1.2 의 파일과 동일한 프로젝트의 버전 1.14 의 파일을 mighthave 합니다.
가서 우리의favorites.txt파일의 버전 1.1 을 변경하자:
blue orange green+cyan definitely not yellow한 번 우리는 변경하든,우리는 실행할 수 있는cvs diff무엇을 보 CVS 생각에는 우리가 ‘vedone:
CVS 인식하는 우리는 추가로 새로운 라인을 포함하는 컬러”청록색”하십시오. (사실,그것은 우리가 만든 변경 사항”RCS”파일을 확인할 수 있다 thatCVS 결코 완전히 탈출 그것의 원래 협회 RCS.)우리가 표시된 diff 는 workingdirectory 의favorites.txt사본과 저장소에 저장된 1.1.1.1 버전 사이의 diff 입니다.
저장소에 저장된 버전을 업데이트하려면 thechange 를 커밋해야합니다. 힘내에서 이것은 다단계 프로세스 일 것입니다. 우리는 그것이 우리의 색인에 나타나도록 thechange 를 스테이지해야 할 것입니다. 그런 다음 우리는 변화를 저지 할 것입니다. 마지막으로 변경 사항을 다른 사람이 볼 수있게하려면 커밋을 원본 저장소로 밀어 올려야합니다.
CVS 에서는cvs commit를 실행할 때 이러한 모든 일이 발생합니다. CVS justbundles 모든 변경 사항은 그것을 찾을 수 있다고 그들에 저장소:
I’m so 사용되는 자식에게는 이것으로 나를 친니다. 기회가 없다면무대 변경,당신이 당신의 작업 감독에서 만진 어떤 오래된 것은 공개 저장소의 일부로 끝납니다. 동료의 잘못 구현 된 기능을 카타르시스 적 필요성에서 벗어나 수동적으로 공격적으로 다루었습니까? 너무 나쁘다,그는 지금 당신이 거시기라고 생각한다. 커밋은 푸시이기 때문에 커밋을 푸시하기 전에 커밋을 편집 할 수 없습니다. 하 youenjoy 지출을 40 분을 반복적으로 실행하는git rebase -i때까지 귀하의 localcommit 역사는 흐름과 같은 파생의 수학적 증거가? 죄송합니다,여기서 그렇게 할 수는 없으며 모든 사람들이 실제로 테스트를 먼저 작성하지 않는다는 것을 알게 될 것입니다.
그러나 나는 또한 왜 그렇게 많은 사람들이 Git 을 불필요하게 복잡하게하는지 이해합니다.는 경우에는cvs commit무엇이 당신을 사용하여,다음 확 준비 및 pushingchanges 것으로 당신을 공격하는 무의미하기 싫은 일이다.
사람들이 Git 이”분산 된”시스템이라는 것에 대해 이야기 할 때,이것은 주로 그들이 의미하는 차이입니다. CVS 에서는 로컬로 커밋을 만들 수 없습니다. 커밋은 다음과 같습니다.코드를 중앙 저장소에 제출하므로 연결을 끊을 수있는 것이 아닙니다. 로컬로 가지고있는 것은 작업 디렉토리입니다. 힘내에서는 본격적인 로컬 리포지토리가 있으므로 연결이 끊어진 상태에서 하루 종일 커밋을 만들 수 있습니다. 그리고 그 커밋을 편집하고,되돌리고,분기하고,다른 사람이 알 필요없이 원하는만큼 선택할 수 있습니다.
커밋이 더 큰 거래 였기 때문에 CVS 사용자는 종종 드물게 만들었습니다.커밋에는 오늘 aten-commit pull request 에서 볼 수있을 것 같은 많은 변경 사항이 포함됩니다. 커밋이 CIbuild 및 자동화 된 테스트 스위트를 트리거 한 경우 특히 그러했습니다.
면 우리는 지금 실행하는cvs status,우리가 볼 수 있습니다 우리는 새로운 버전의 파일:
병합
위에서 언급했듯이 CVS 편집할 수 있는 파일에 다른 사람은 alreadyediting. 그것은 RCS 에 대한 CVS 의 큰 개선이었습니다. 변경 사항을 다시 함께 가져 가야 할 때 어떻게됩니까?자신이 좋아하는 색상을 추가하기 위해 친구를 초대했다고 가정 해 봅시다.당신의 목록. 그들은 자신의 색상을 추가하는 동안,당신은 당신이 더 이상 색상을 녹색으로 결정하고 목록에서 제거합니다.
에 갈 때 당신 변경 사항을 적용을 발견할 수 있습 CVS 통지 문제가 있:
처럼 보이는 친구들을 위해 각 변경사항들이 처음이다. 따라서favorites.txt의 버전은 저장소의 버전과 최신 상태가 아닙니다. 는 경우 youruncvs statusfavorites.txt은 version1.2 으로 일부 지역의 변화,그러나 저장소에 1.3 버전:
실행할 수 있습니다cvs diff을 정확히 확인 사이의 차이점이 무엇인 1.2and1.3:
것 같이 우리의 친구들이 정말 좋아하는 분홍색이다. 어쨌든 그들은 편집했습니다.우리가 가지고있는 것보다 파일의 다른 부분,그래서 변경 사항은 병합하기 쉽습니다. CVScan 을 위해 그렇게 할 때 우리는 우리가 실행하는cvs updategit pull
$ cvs updatecvs update: Updating .RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,vretrieving revision 1.2retrieving revision 1.3Merging differences between 1.2 and 1.3 into favorites.txtM favorites.txt경우 지금 봐favorites.txt, 당신이 beenmodified 변경 사항을 포함하는 친구가 만들어하는 파일입니다. 당신의 변경도 여전히 거기에 있습니다. 지금 당신은 무료로 commit 파일:
최종 결과는 당신이 무엇을 말 Git 실행하여git pull --rebase. Yourchanges 는 친구의 변경 사항 위에 추가되었습니다. “Mergecommit”이 없습니다.”
때로는 동일한 파일에 대한 변경 사항이 호환되지 않을 수 있습니다. 친구가”녹색”을”올리브”로 변경했다면,예를 들어”녹색”을 모두 제거하는 것과 충돌했을 것입니다. CVS 의 초기에,이것은 정확한사람들이 CVS 가 안전하지 않다고 걱정하게 만든 종류의 사례; RCS’pessimistic 잠금은 그러한 경우가 결코 발생할 수 없음을 보장했습니다. 그러나 아무도 변경 사항이 overrittenautomatically 얻을 수 있는지 확인하여 안전을 CVSguarantees. 당신에게 말해야 CVS 는 변경을 유지하려면 goingforward,그래서 실행할 때는cvs update,CVS 마크 파일로 모두 changesin 같은 방법으로 Git 때 Git 감지 병합 충돌이 있습니다. 그런 다음 수동으로 파일을 편집하고 유지하려는 변경 사항을 선택하십시오.
여기서 주목해야 할 흥미로운 점은 병합 충돌을 해결해야한다는 것입니다.커밋 할 수 있습니다. 이것은 또 다른 결과의 CVS’중앙 집중식 자연입니다.Git 을 사용하면,당신을 걱정할 필요가 없 해결에 대해 병합될 때까지 당신은 밀어 thecommits 있습니다.
태그 및 가지
이후 CVS 지 않게 가능 커밋 개체하는 유일한 방법 groupa 컬렉션의 변화를 표시하는 특별한 작업 디렉터리 상태 atag.
을 만드는 태그는 것은 쉽습니다:
$ cvs tag VERSION_1_0cvs tag: Tagging .T favorites.txt신 후 반환 할 수 있는 파일을 이 상태를 실행하여cvs updateandpassing 태그는-r플래그:
$ cvs update -r VERSION_1_0cvs update: Updating .U favorites.txt필요가 있기 때문에 태그가 되감기는 앞서 작업 디렉터리 상태,CVSencourages 많이 선점을 줍니다. 기 전에 주요 리팩터링,예를 들어,당신이를 만들 수 있습니다BEFORE_REFACTOR_01태그할 수 있는 나중에 사용하는 경우 therefactor 잘못했습니다. 사람들은 또한 일반화하려는 경우 태그를 사용했습니다.프로젝트 전체 diffs. 기본적으로 commithashes 로 오늘날 우리가 일상적으로 수행하는 모든 일은 cvs 와 함께 예상되고 계획되어야합니다.
분기는 일종의 CVS 에서 만들 수 있습니다. 가지는 특별한 종류 oftag:
$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors를 생성하는 지점(전체보기에서 모든 사람의 방법에 의해),그래서 youstill 로 전환해야 사용하여cvs update:
$ cvs update -r TRY_EXPERIMENTAL_THING위의 명령을위에 새로운 지점에서 당신의 현재 workingdirectory,하지만 실용적인 버전을 사용하여 제어 CVS 실제로 조언한 것을 만들 새로운 디렉토리를 보유하는 새로운 지점입니다. 아마도 저자들은 cvs 에서 분기를 전환하는 것보다 디렉토리를 전환하는 것이 더 쉽다는 것을 알았을 것입니다.
Cvs 를 사용하는 실용적인 버전 제어는 기존 분기의 branchesoff 를 만드는 것에 대해서도 조언합니다. 그들은 Git 에서master로 알려진 themainline 브랜치에서 브랜치 만 만드는 것이 좋습니다. 일반적으로 분기는”고급”CVS 기술을 고려했습니다. Git 을 사용하면,당신은 수 있는 새로운 지점을 시작 foralmost 모든 사소한 이유가 있지만,CVS 분기 일반적으로만 사용 whenreally 필요한 등을 위해 출시하였습니다.
A 지점할 수 있는 나중에 병합할 수 있으로 다시 주류 사용하는cvs update-j플래그:
$ cvs update -j TRY_EXPERIMENTAL_THING에 대한 감사 Commit 역사
2007 년에,리누스 토발즈 준 atalk 에 대한 Git Google. Git 은 매우 새롭기 때문에 토크는 기본적으로 git 이 사용 가능한 것과는 다르더라도 git 을 사용해야한다는 넓은 프로그래머를 설득하려는 시도였습니다. 당신이 이미 이야기를 보지 못했다면,그것을 보도록 권유하십시오. 리누스는 재미있는 스피커입니다,henever 는 자신의 성급한 자아가 될 실패하더라도. 그는 이유를 설명하는 훌륭한 일을합니다.버전 제어의 분산 모델은 중앙 집중식 모델보다 낫습니다. 그의 비판의 많은 특히 CVS 를 위해 예약되어 있습니다.Git 은 복잡한 도구입니다. 그것을 배우는 것은 재미있는 경험이 될 수 있습니다. 그러나 나는 또한 Gitcan 이하는 일에 계속해서 놀랐다. 비교해 보면 CVS 는 간단하고 간단하지만 종종 우리가 지금 당연시하는 많은 작업을 수행 할 수는 없습니다. 다시 가을 사용하여 CVSfor 동안 탁월한 방법으로 자신을 발견하는 새로운 감사 forGit 의 능력 및 유연성을 제공합니다. 그것은 잘 보여 줍니다 왜 이해 historyof 소프트웨어 개발할 수 있도록 도움이 따기하고 다시 examiningobsolete 도구 가르 칠 것입니다 당신이 볼륨에 대한 뒤에 이유를 우리는 도구 usetoday.
이 게시물을 즐겼다면 4 주마다 더 많이 나옵니다! Twitter 에서@TwoBitHistory 를 팔로우하거나 RSS 피드를 구독하십시오.새 게시물이 언제 나오는지 확인하십시오.
Correction
는데 있다는 것을 많은 조직들,특히 위험 adverseorganizations 는 것을 만들 의료 장비 소프트웨어,여전히 useCVS. 프로그래머는 이러한 조직 개발은 forworking 주변의 CVS’한 제한과 같은 새로운 지점을 위해 거의 everychange 저지르고 피하기 위해 직접HEAD. (Michael Kohne 에게 감사드립니다.이것을 지적했습니다.)