깃

Git
기타 용도는 Git(동음이의)을 참조하십시오.
GitHub, GitLab, Gitea와 혼동하지 마십시오.
깃
원본 작성자리누스 토발스[1]
개발자하마노[2] 주니오 외
초기출시2005년 4월 7일; 18년 전 (2005-04-07)
안정적 해제
2.42.0[3] / 2023년 8월 21일
저장소
기재.주로 C에서 GUI 및 프로그래밍 스크립트가 셸 스크립트, Perl, Tcl 및 Python으로[4][5] 작성됨
운영체제POSIX(리눅스, macOS, Solaris, AIX), Windows
에서 사용 가능영어
유형버전 제어
면허증.GPL-2.0 전용[i][7]
웹사이트git-scm.com Edit this on Wikidata

Git(// ɡɪt/)는 소프트웨어 개발 중에 소스 코드를 공동 개발하는 프로그래머들 사이에서 작업을 조정하기 위해 사용되는 컴퓨터 파일 집합의 변경 사항을 추적하는 분산 버전 제어 시스템입니다.목표는 속도, 데이터 무결성 및 비선형 분산 워크플로우(서로 다른 컴퓨터에서 실행되는 수천 개의 병렬 지점) 지원입니다.[10][11][12]

깃은 원래 리눅스 커널 개발을 위해 2005년 리누스 토르발스에 의해 저작되었으며 다른 커널 개발자들이 초기 개발에 기여했습니다.[13]2005년부터 하마노 주니오가 핵심 정비사로 일하고 있습니다.다른 대부분의 분산 버전 제어 시스템과 대부분의 클라이언트-서버 시스템과 달리 모든 컴퓨터의 모든 Git 디렉토리는 네트워크 액세스나 중앙 서버에 관계없이 완전한 이력과 완전한 버전 추적 기능을 갖춘 완전한 저장소입니다.[14]Git는 GPL-2.0 전용 라이선스 하에 공유되는 자유-오픈 소스 소프트웨어입니다.

깃은 개발 이후 가장 대중적인 분산 버전 제어 시스템으로 자리 잡았으며, 2022년 기준 개발자의 95% 가까이가 주요 버전 제어 시스템으로 보고하고 있습니다.[15]GitHub, SourceForge, Bitbucket 및 GitLab을 포함한 많은 인기 있는 Git 저장소 서비스가 있습니다.[16][17][18][19][20]

역사

Git 개발은 2002년부터 리눅스 커널 개발에 사용된 독점적 소스-제어 관리(SCM) 시스템인 비트키퍼가 리눅스 개발을 위한 무료 라이선스를 취소하면서 2005년 4월 Torvalds에 의해 시작되었습니다.[21][22]BitKeeper의 저작권자인 Larry McVoy는 Andrew Tridgell이 BitKeeper 프로토콜을 역공학하여 SourcePuller를 만들었다고 주장했습니다.[23]같은 사건이 또 다른 버전 제어 시스템인 Mercurial의 탄생을 촉진시켰습니다.

Torvalds는 BitKeeper와 같이 사용할 수 있는 분산 시스템을 원했지만 사용 가능한 무료 시스템 중 어느 것도 그의 요구를 충족시키지 못했습니다.그는 패치를 적용하고 모든 관련 메타데이터를 업데이트하는 데 30초가 소요되는 소스-제어 관리 시스템의 예를 들며, 이는 동료 유지 관리자와 동기화하는 데 한 번에 250개의 그러한 작업이 필요한 Linux 커널 개발의 요구사항으로 확장되지 않을 것이라고 언급했습니다.설계 기준을 위해 패치 적용에는 3초 이상이 걸리지 않아야 한다고 명시하고 다음과 같은 세 가지 목표를 추가했습니다.[10]

  • CVS(Concurrent Version System)를 하지 말아야 할 일의 예로 들고, 의심스러운 경우 정반대의 결정을 내립니다.[12]
  • 분산된 BitKeeper와 유사한 워크플로우를 지원합니다.[12]
  • 우발적이든 악의적이든 부패에 대한 매우 강력한 보호 장치를 포함합니다.[11]

이 기준은 당시 사용 중이던 모든 버전 제어 시스템을 제거했기 때문에 2.6.12-rc2 리눅스 커널 개발 릴리스 직후 Torvalds는 자신의 버전을 작성하기 시작했습니다.[12]

Git의 개발은 2005년 4월 3일에 시작되었습니다.[24]토발즈는 4월 6일에 프로젝트를 발표했고 다음날에 자체적으로 진행하게 되었습니다.[24][25]여러 지점의 첫 합병은 4월 18일에 이루어졌습니다.[26]Torvalds는 성능 목표를 달성했습니다. 4월 29일, 초기 Git은 초당 6.7개의 패치 속도로 리눅스 커널 트리에 패치를 기록하는 벤치마크가 되었습니다.[27]6월 16일, 깃은 커널 2.6.12 릴리스를 관리했습니다.[28]

토벌즈는 2005년 7월 26일에 프로젝트의 주요 기여자인 준오 하마노에게 정비를 맡겼습니다.[29]하마노는 2005년 12월 21일 1.0 출시를 담당했습니다.[30]

작명

토르발스는 깃(Git, 영국 영어 속어로 "불쾌한 사람"이라는 뜻)이라는 이름에 대해 비꼬았습니다."나는 이기적인 서자이고, 내 모든 프로젝트의 이름을 내 이름을 따서 짓습니다.처음에는 '리눅스', 지금은 '깃'."[31][32]맨 페이지는 깃을 "바보 콘텐츠 추적기"라고 설명합니다.[33]소스 코드의 read-me 파일은 다음과 같이 자세히 설명합니다.[34]

"깃"은 기분에 따라 무엇이든 의미할 수 있습니다.

  • 발음이 가능하고 일반적인 UNIX 명령에서는 실제로 사용되지 않는 임의의 세 글자 조합입니다."get"의 잘못된 발음이라는 사실은 관련이 있을 수도 있고 그렇지 않을 수도 있습니다.
  • 멍청하고 경멸스럽고 비열한 놈.간단하죠.비속어 사전에서 골라보세요.
  • "글로벌 정보 추적기": 당신은 기분이 좋고, 실제로 당신에게 효과가 있습니다.천사들이 노래를 부르고, 갑자기 빛이 방을 가득 채웁니다.
  • "세상에 바보 같은 트럭들이 가득 찼어": 깨질 때.

Git의 소스 코드는 프로그램을 "지옥에서 온 정보 관리자"라고 말합니다.

릴리스

깃 릴리스 목록:[35]

버전 원출시일자 최신 (패치) 버전 패치해제일자 눈에 띄는 변경 사항
이전 버전, 더 이상 유지되지 않음: 0.99 2005-07-11 0.99.9n 2005-12-15
이전 버전, 더 이상 유지되지 않음: 1.0 2005-12-21 1.0.13 2006-01-27
이전 버전, 더 이상 유지되지 않음: 1.1 2006-01-08 1.1.6 2006-01-30
이전 버전, 더 이상 유지되지 않음: 1.2 2006-02-12 1.2.6 2006-04-08
이전 버전, 더 이상 유지되지 않음: 1.3 2006-04-18 1.3.3 2006-05-16
이전 버전, 더 이상 유지되지 않음: 1.4 2006-06-10 1.4.4.5 2008-07-16
이전 버전, 더 이상 유지되지 않음: 1.5 2007-02-14 1.5.6.6 2008-12-17
이전 버전, 더 이상 유지되지 않음: 1.6 2008-08-17 1.6.6.3 2010-12-15
이전 버전, 더 이상 유지되지 않음: 1.7 2010-02-13 1.7.12.4 2012-10-17
이전 버전, 더 이상 유지되지 않음: 1.8 2012-10-21 1.8.5.6 2014-12-17
이전 버전, 더 이상 유지되지 않음: 1.9 2014-02-14 1.9.5 2014-12-17
이전 버전, 더 이상 유지되지 않음: 2.0 2014-05-28 2.0.5 2014-12-17
이전 버전, 더 이상 유지되지 않음: 2.1 2014-08-16 2.1.4 2014-12-17
이전 버전, 더 이상 유지되지 않음: 2.2 2014-11-26 2.2.3 2015-09-04
이전 버전, 더 이상 유지되지 않음: 2.3 2015-02-05 2.3.10 2015-09-29
이전 버전, 더 이상 유지되지 않음: 2.4 2015-04-30 2.4.12 2017-05-05
이전 버전, 더 이상 유지되지 않음: 2.5 2015-07-27 2.5.6 2017-05-05
이전 버전, 더 이상 유지되지 않음: 2.6 2015-09-28 2.6.7 2017-05-05
이전 버전, 더 이상 유지되지 않음: 2.7 2015-10-04 2.7.6 2017-07-30
이전 버전, 더 이상 유지되지 않음: 2.8 2016-03-28 2.8.6 2017-07-30
이전 버전, 더 이상 유지되지 않음: 2.9 2016-06-13 2.9.5 2017-07-30
이전 버전, 더 이상 유지되지 않음: 2.10 2016-09-02 2.10.5 2017-09-22
이전 버전, 더 이상 유지되지 않음: 2.11 2016-11-29 2.11.4 2017-09-22
이전 버전, 더 이상 유지되지 않음: 2.12 2017-02-24 2.12.5 2017-09-22
이전 버전, 더 이상 유지되지 않음: 2.13 2017-05-10 2.13.7 2018-05-22
이전 버전, 더 이상 유지되지 않음: 2.14 2017-08-04 2.14.6 2019-12-07
이전 버전, 더 이상 유지되지 않음: 2.15 2017-10-30 2.15.4 2019-12-07
이전 버전, 더 이상 유지되지 않음: 2.16 2018-01-17 2.16.6 2019-12-07
이전 버전, 더 이상 유지되지 않음: 2.17 2018-04-02 2.17.6 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.18 2018-06-21 2.18.5 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.19 2018-09-10 2.19.6 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.20 2018-12-09 2.20.5 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.21 2019-02-24 2.21.4 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.22 2019-06-07 2.22.5 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.23 2019-08-16 2.23.4 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.24 2019-11-04 2.24.4 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.25 2020-01-13 2.25.5 2021-03-09 희박한 체크아웃 관리로 간편해졌습니다[36].
이전 버전, 더 이상 유지되지 않음: 2.26 2020-03-22 2.26.3 2021-03-09
  • 프로토콜 버전 2가 기본값입니다.
  • 몇 가지 새로운 구성 요령
  • git sparse-checkout 업데이트

[37]

이전 버전, 더 이상 유지되지 않음: 2.27 2020-06-01 2.27.1 2021-03-09
이전 버전, 더 이상 유지되지 않음: 2.28 2020-07-27 2.28.1 2021-03-09
  • 소개하는init.defaultBranch
  • 변경 경로 블룸 필터

[38]

이전 버전, 더 이상 유지되지 않음: 2.29 2020-10-19 2.29.3 2021-03-09
  • 실험용 SHA-256 지원
  • 음의 refspecs
  • 신규git shortlog묘기

[39]

이전 버전, 아직도 유지됨: 2.30 2020-12-27 2.30.9 2023-04-25
  • PHP 업데이트, Rust, CSS 업데이트를 위한 Userdiff
  • 명령행 완료 스크립트(contribute/)는 "git stash show"가 "git diff"가 취하는 옵션을 사용한다는 것을 배웠습니다.

[40]

이전 버전, 아직 유지됨: 2.31 2021-03-15 2.31.8 2023-04-25
  • git difftool덧셈--skip-to선택
  • --format기계 판독이 가능하도록 향상된 기능
  • git pull기본 재배치 또는 병합을 지정하도록 경고

[41][42]

이전 버전, 여전히 유지됨: 2.32 2021-06-06 2.32.7 2023-04-25
이전 버전, 아직 유지됨: 2.33 2021-08-16 2.33.8 2023-04-25
이전 버전, 아직 유지됨: 2.34 2021-11-15 2.34.8 2023-04-25
이전 버전, 아직도 유지됨: 2.35 2022-01-25 2.35.8 2023-04-25
이전 버전, 여전히 유지됨: 2.36 2022-04-18 2.36.6 2023-04-25
이전 버전, 아직 유지됨: 2.37 2022-06-27 2.37.7 2023-04-25
이전 버전, 아직도 유지됨: 2.38 2022-10-02 2.38.5 2023-04-25
이전 버전, 여전히 유지됨: 2.39 2022-12-12 2.39.3 2023-04-25
이전 버전, 아직도 유지됨: 2.40 2023-03-14 2.40.1 2023-04-25
현재 안정 버전: 2.41 2023-06-01 2.41.0
범례:
구본
이전 버전, 여전히 유지됨
최신 버전
최신 미리보기 버전
향후 출시
출처:[43][44]

설계.

깃의 디자인은 비트키퍼와 모노톤에서 영감을 얻었습니다.[45][46]Git는 원래 낮은 수준의 버전 제어 시스템 엔진으로 설계되었으며, 그 위에 Cogito 또는 StGIT와 같은 프론트엔드를 작성할 수 있습니다.[46]이후 핵심 Git 프로젝트는 직접 사용할 수 있는 완벽한 버전 제어 시스템이 되었습니다.[47]Torvalds는 BitKeeper의 강한 영향을 받았지만, 의도적으로 기존의 접근 방식을 피하여 독특한 디자인을 만들었습니다.[48]

특성.

Git의 디자인은 Torvalds가 대규모 분산 개발 프로젝트를 유지하는 데 있어 경험을 종합한 것으로, 동일한 프로젝트에서 얻은 파일 시스템 성능에 대한 친밀한 지식과 짧은 순서로 작동하는 시스템을 생산해야 하는 시급한 필요성이 함께 있습니다.이러한 영향으로 인해 다음과 같은 구현 선택이 이루어졌습니다.[49]

비선형 개발에 대한 강력한 지원
Git는 신속한 분기 및 병합을 지원하며 비선형 개발 이력을 시각화하고 탐색하기 위한 특정 도구를 포함합니다.Git에서 핵심적인 가정은 변경 사항이 여러 검토자에게 전달되기 때문에 작성된 것보다 더 자주 병합된다는 것입니다.Git에서 분기는 매우 가볍습니다. 분기는 하나의 커밋에 대한 참조일 뿐입니다.부모 커밋을 사용하면 전체 분기 구조를 구성할 수 있습니다.[improper synthesis?]
분산개발
Darcs, BitKeeper, Mercurial, Baza, Monotone과 마찬가지로 Git은 각 개발자에게 전체 개발 이력의 로컬 복사본을 제공하고 변경 사항은 한 저장소에서 다른 저장소로 복사됩니다.이러한 변경 사항은 추가된 개발 분기로 가져오며 로컬에서 개발된 분기와 동일한 방법으로 병합할 수 있습니다.[50]
기존 시스템 및 프로토콜과의 호환성
리포지토리는 HTTP(Hypertext Transfer Protocol Secure), HTTP(Hypertext Transfer Protocol), FTP(File Transfer Protocol) 또는 일반 소켓 또는 SSH(Secure Shell)를 통해 Git 프로토콜을 통해 게시할 수 있습니다.Git에는 기존 CVS 클라이언트와 IDE 플러그인을 사용하여 Git 저장소에 액세스할 수 있는 CVS 서버 에뮬레이션도 있습니다.체제 전복 저장소는 git-svn과 함께 직접 사용할 수 있습니다.[51]
대형 프로젝트의 효율적인 처리
Torvalds는 Git가 매우 빠르고 확장성이 있다고 [52]설명했으며, Mozilla가[53] 수행한 성능 테스트에서는 Mercurial과 GNU Baza보다 대용량 저장소를 훨씬 빠르게 이동하는 것으로 나타났습니다. 로컬에 저장된 저장소에서 버전 기록을 가져오는 것이 원격 서버에서 가져오는 것보다 100배 더 빠를 수 있습니다.[54]
이력 암호화 인증
Git 이력은 특정 버전의 ID(Git 용어의 커밋)가 해당 커밋에 이르는 전체 개발 이력에 따라 결정되도록 저장됩니다.게시된 후에는 이전 버전을 변경할 수 없습니다.구조는 머클 나무와 비슷하지만 마디와 잎에 데이터가 추가되어 있습니다.[55] (머큐리얼과 모노톤에도 이 속성이 있습니다.)
툴킷 기반 설계
Git는 C로 작성된 프로그램 세트와 해당 프로그램 주변에 래퍼를 제공하는 여러 셸 스크립트로 설계되었습니다.[56]이후 대부분의 스크립트가 속도와 휴대성을 위해 C로 다시 작성되었지만, 설계는 그대로 남아 있으며 구성 요소를 서로 연결하는 것이 쉽습니다.[57]
플러그형 병합 전략
툴킷 디자인의 일환으로 Git에는 불완전한 병합 모델이 잘 정의되어 있으며, 이를 완료하기 위한 여러 알고리즘이 있어 사용자에게 자동으로 병합을 완료할 수 없으며 수동 편집이 필요하다는 것을 알려줍니다.[58]
수거할 때까지 쓰레기가 쌓임
작업을 중단하거나 변경 사항을 백업하면 데이터베이스에 아무 소용이 없는 개체가 남게 됩니다.이러한 것들은 일반적으로 지속적으로 증가하고 있는 수배 대상들의 역사에서 작은 부분을 차지합니다.저장소에 느슨한 개체가 충분히 생성되면 Git에서 가비지 컬렉션을 자동으로 수행합니다.가비지 컬렉션은 다음을 사용하여 명시적으로 호출할 수 있습니다.git gc.[59][60]
주기적 명시적 개체 패킹
Git는 새로 생성된 각 개체를 별도의 파일로 저장합니다.개별적으로 압축되기는 하지만 이는 공간을 많이 차지하고 비효율적입니다.이 문제는 델타 압축된 수많은 개체를 팩 파일이라고 하는 하나의 파일(또는 네트워크 바이트 스트림)에 저장하는 팩을 사용함으로써 해결됩니다.팩은 이름이 같은 파일이 유사할 수 있다는 휴리스틱을 사용하여 압축되며, 정확성은 이 파일에 의존하지 않습니다.각 팩 파일에 대해 해당 인덱스 파일이 생성되어 팩 파일의 각 개체의 오프셋을 알려줍니다.새로 생성된 개체(새로 추가된 이력이 있는 개체)는 여전히 단일 개체로 저장되며, 공간 효율성을 유지하기 위해서는 주기적인 재포장이 필요합니다.저장소를 패킹하는 프로세스는 계산 비용이 많이 들 수 있습니다.Git은 느슨하지만 빠르게 생성된 형식으로 저장소에 개체를 존재시킬 수 있도록 함으로써 시간 문제가 덜 되는 시간(예: 근무일 종료)까지 값비싼 팩 작업을 지연시킬 수 있습니다.Git는 주기적인 재패킹을 자동으로 하지만 수동 재패킹도 가능합니다.git gc지휘.[61]데이터 무결성을 위해 팩 파일과 인덱스 모두 내부에 SHA-1 체크섬이[62] 있으며 팩 파일의 파일 이름에도 SHA-1 체크섬이 포함되어 있습니다.리포지토리의 무결성을 검사하려면git fsck지휘.[63][64]

Git의 또 다른 특성은 파일의 디렉토리 트리를 스냅샷한다는 것입니다.소스 코드의 버전을 추적하는 최초의 시스템인 소스 코드 제어 시스템(SCCS)과 개정 제어 시스템(RCS)은 개별 파일을 작업했으며 인터리브 델타(SCCS) 또는 델타 인코딩(RCS)을 통해 얻을 수 있는 공간 절약을 강조했습니다.이후 개정 제어 시스템은 프로젝트의 여러 개정에 걸쳐 동일성을 갖는 파일의 개념을 유지했습니다.그러나 Torvalds는 이 개념을 거부했습니다.[65]따라서 Git는 소스-코드 트리 아래의 어떤 수준에서도 파일 수정 관계를 명시적으로 기록하지 않습니다.

이러한 암묵적인 수정 관계는 다음과 같은 몇 가지 중요한 결과를 가져옵니다.

  • 한 파일의 변경 내역을 조사하는 것은 전체 프로젝트보다 비용이 조금 더 듭니다.[66]지정된 파일에 영향을 미치는 변경 내역을 얻으려면 Git은 전역 내역을 확인한 다음 각 변경 사항이 해당 파일을 수정했는지 여부를 확인해야 합니다.그러나 히스토리를 검사하는 이 방법은 Git가 동일한 효율로 임의의 파일 집합에 대한 변경 사항을 보여주는 단일 히스토리를 생성하도록 합니다.예를 들어 소스 트리의 하위 디렉터리와 관련 글로벌 헤더 파일이 포함된 경우가 매우 일반적입니다.
  • 이름 변경은 명시적이 아닌 암묵적으로 처리됩니다.CVS의 일반적인 불만 사항은 파일 이름을 사용하여 수정 내역을 식별하기 때문에 파일의 기록을 중단하거나 기록 이름을 변경하지 않고는 파일을 이동하거나 이름을 바꿀 수 없으며 이로 인해 기록이 부정확하게 됩니다.대부분의 사후 CVS 리비전-제어 시스템은 파일에 이름을 변경해도 남는 고유한 긴 수명 이름(아이노드 번호와 유사)을 부여하여 이 문제를 해결합니다.깃은 그러한 식별자를 기록하지 않으며, 이것이 장점이라고 주장합니다.[67][68]소스 코드 파일은 분할되거나 병합되거나 단순히 이름이 변경되는 경우가 있으며,[69] 단순한 이름 변경으로 기록하면 (불변) 기록에서 발생한 일에 대한 부정확한 설명이 동결됩니다.Git는 스냅샷을 생성할 때 기록하는 것이 아니라 스냅샷의 이력을 탐색하는 동안 이름을 변경하여 이 문제를 해결합니다.([70]간략, 개정 N의 파일을 고려하면 개정 N - 1의 동일한 이름의 파일이 기본 상위 파일입니다.그러나 개정판 N - 1에 동일한 이름의 파일이 없을 경우, Git은 개정판 N - 1에만 존재하고 새로운 파일과 매우 유사한 파일을 검색합니다.)그러나 이력을 검토할 때마다 CPU 집약적인 작업이 필요하며 휴리스틱을 조정하는 몇 가지 옵션을 사용할 수 있습니다.이 메커니즘이 항상 작동하는 것은 아니며, 동일한 커밋의 변경으로 이름이 변경된 파일은 이전 파일의 삭제 및 새 파일의 작성으로 읽히기도 합니다.개발자는 이름 변경과 변경을 별도로 커밋하여 이 제한을 해결할 수 있습니다.

Git는 몇 가지 병합 전략을 구현하며, 병합 시 기본값이 아닌 전략을 선택할 수 있습니다.[71]

  • resolve: 전통적인 3자 병합 알고리즘.
  • 재귀적:이것은 분기 하나를 당기거나 병합할 때의 기본값이며, 3원 병합 알고리즘의 변형입니다.

    3방향 병합에 사용할 수 있는 공통 조상이 둘 이상 있을 경우 공통 조상의 병합 트리를 생성하고 이를 3방향 병합의 참조 트리로 사용합니다.이로 인해 리눅스 2.6 커널 개발 기록에서 가져온 이전 병합 커밋에 대해 수행된 테스트를 통해 잘못된 병합을 야기하지 않으면서 병합 충돌이 더 적게 발생하는 것으로 보고되었습니다.또한 이름 변경과 관련된 병합을 탐지하고 처리할 수 있습니다.

    — Linus Torvalds[72]
  • 문어:두 개 이상의 헤드를 병합하는 경우 기본값입니다.

데이터 구조

Git의 프리미티브는 본질적으로 소스 코드 관리 시스템이 아닙니다.Torvalds는 다음과 같이 설명합니다.[73]

여러 가지 면에서 그냥 파일 시스템으로 볼 수 있습니다. 컨텐츠 주소 지정이 가능하고 버전 지정이라는 개념도 있지만, 실제로는 파일 시스템 담당자의 관점에서 문제가 발생하는 것을 설계했습니다(커널은 제가 하는 일입니다). 그리고 저는 기존 SCM 시스템을 만드는 데 전혀 관심이 없습니다.

이러한 초기 설계 방식에서 Git은 기존 SCM에서 예상되는 모든 기능을 개발했으며,[47] 대부분 필요에 따라 생성된 기능을 시간이 지남에 따라 정제 및 확장했습니다.

Git 리비전 제어 시스템의 일부 데이터 흐름 및 스토리지 수준

Git에는 두 가지 데이터 구조가 있습니다. 작업 디렉토리와 커밋할 다음 수정사항에 대한 정보를 캐시하는 가변 인덱스(스테이지 또는 캐시라고도 함)와 불변의 추가 전용 객체 데이터베이스입니다.

인덱스는 개체 데이터베이스와 작업 트리 사이의 연결점 역할을 합니다.

개체 데이터베이스에는 다음과 같은 다섯 가지 유형의 개체가 있습니다.[74][63]

  • blob(binary large object)은 파일의 내용입니다.Blobs에는 적절한 파일 이름, 타임스탬프 또는 기타 메타데이터가 없습니다(A blob의 이름은 내부적으로 해당 콘텐츠의 해시입니다).[75]각 블롭은 파일의 버전이기 때문에 파일의 데이터를 보유합니다.[76]
  • 트리 개체는 디렉토리와 동등한 개체입니다.파일 이름 목록이 포함되어 있으며,[77] 각 파일 이름은 일부 유형 비트와 해당 파일, 심볼릭 링크 또는 디렉터리 내용인 blob 또는 트리 개체에 대한 참조입니다.이 개체는 원본 트리의 스냅샷입니다.(전체적으로, 이것은 Merkle 트리로 구성되는데, 이것은 루트 트리에 대한 하나의 해시만으로도 충분하며 실제로 커밋에서 임의의 수의 하위 디렉토리와 파일의 전체 트리 구조의 정확한 상태를 정확하게 파악하기 위해 사용됩니다.)
  • 커밋 개체는 트리 개체를 기록으로 연결합니다.트리 개체의 이름(최상위 원본 디렉터리), 타임스탬프, 로그 메시지 및 0개 이상의 상위 커밋 개체의 이름이 포함되어 있습니다.[78]
  • 태그 개체는 다른 개체에 대한 참조를 포함하고 있으며 다른 개체와 관련된 추가 메타 데이터를 보관할 수 있는 컨테이너입니다.가장 일반적으로 Git에 의해 추적되는 데이터의 특정 릴리스에 해당하는 커밋 개체의 디지털 서명을 저장하는 데 사용됩니다.[79]
  • packfile 개체는 네트워크 프로토콜을 통한 압축 및 전송 용이성을 위해 zlib 압축 번들로 다양한 다른 개체를 수집합니다.[80]

각 개체는 해당 내용의 SHA-1 해시로 식별됩니다.Git는 해시를 계산하고 이 값을 개체 이름에 사용합니다.개체는 해시의 처음 두 문자와 일치하는 디렉토리에 저장됩니다.나머지 해시는 해당 개체의 파일 이름으로 사용됩니다.

Git는 파일의 각 리비전을 고유 블롭으로 저장합니다.방울 사이의 관계는 나무와 커밋 물체를 조사함으로써 알 수 있습니다.새로 추가된 개체는 zlib 압축을 사용하여 전체적으로 저장됩니다.이렇게 하면 많은 디스크 공간을 빠르게 사용할 수 있으므로 객체를 팩으로 결합할 수 있습니다. 이 팩은 공간을 절약하기 위해 델타 압축을 사용하여 다른 블롭과 비교하여 블롭을 변경 사항으로 저장합니다.

또한 git는 refs(references의 줄임말)라는 레이블을 저장하여 다양한 커밋의 위치를 나타냅니다.참조 데이터베이스에 저장되며 각각 다음과 같습니다.[81]

  • 헤드(브랜치):커밋을 수행할 때 새 커밋으로 자동으로 고급되는 명명된 참조.
  • 헤드: 작업 트리와 비교하여 커밋을 생성하는 예비 헤드입니다.
  • 태그: 분기 참조와 같지만 특정 커밋에 고정됩니다.역사에서 중요한 점에 레이블을 지정하는 데 사용됩니다.

참고문헌

참조되지 않은 Git 데이터베이스의 모든 개체는 가비지 컬렉션 명령을 사용하거나 자동으로 정리할 수 있습니다.개체는 다른 개체 또는 명시적 참조에 의해 참조될 수 있습니다.Git은 다양한 종류의 참조를 알고 있습니다.참조를 생성, 이동 및 삭제하는 명령은 다양합니다.git show-ref모든 참조를 나열합니다.일부 유형은 다음과 같습니다.

  • heads: 로컬에서 객체를 가리킵니다.
  • remotes: 원격 저장소에 존재하는 개체를 가리킵니다.
  • stash: 아직 커밋되지 않은 개체를 가리킵니다.
  • meta: 예를 들어 베어 저장소의 구성, 사용자 권한, refs/meta/config 네임스페이스가 소급적으로 도입되어 Gerrit에 의해 사용됩니다.[82]
  • 태그: 위를 참조하십시오.

구현

gitg는 GTK+를 사용하는 그래픽 프론트엔드입니다.

Git(C의 주요 구현)은 주로 리눅스에서 개발되지만 BSD(DragonFly BSD, FreeBSD, NetBSD, OpenBSD), Solaris, macOS, Windows 등 대부분의 주요 운영 체제도 지원합니다.[83][84]

Git의 첫 번째 Windows 포트는 주로 Linux 버전을 호스팅하는 Linux 에뮬레이션 프레임워크였습니다.윈도우 아래에 Git을 설치하면 GNU 컴파일러 컬렉션의 Mingw-w64 포트, Perl 5, MSYS2(자체는 윈도우용 유닉스와 유사한 에뮬레이션 환경인 Cygwin의 분기)와 리눅스 유틸리티 및 라이브러리의 다양한 다른 윈도우 포트 또는 에뮬레이션이 포함된 비슷한 이름의 프로그램 파일 디렉토리가 생성됩니다.현재 Git의 기본 Windows 빌드는 32비트 및 64비트 설치 프로그램으로 배포됩니다.[85]git 공식 웹사이트는 현재 MSYS2 환경을 여전히 사용하면서 Windows용 Git 빌드를 유지하고 있습니다.[86]

Git의 JGit 구현은 순수 자바 소프트웨어 라이브러리로, 모든 자바 애플리케이션에 내장되도록 설계되었습니다.JGit은 게릿 코드 리뷰 도구와 이클립스 IDE의 Git 클라이언트인 EGit에서 사용됩니다.[87]

Go-git은 순수 Go로 작성된 Git의 오픈 소스 구현입니다.[88]현재 Git 코드 저장소에[89] 대한 SQL 인터페이스로 프로젝트를 지원하고 Git에 대한 암호화를 제공하는 데 사용됩니다.[90]

Git의 Dulwich 구현은 Python 2.7, 3.4 및 3.5용 순수 Python 소프트웨어 구성 요소입니다.[91]

Git의 libgit2 구현은 다른 종속성이 없는 ANSIC 소프트웨어 라이브러리로, Windows, Linux, macOS 및 BSD를 포함한 여러 플랫폼에 구축할 수 있습니다.[92]루비, 파이썬, 하스켈을 포함한 많은 프로그래밍 언어에 대한 바인딩을 가지고 있습니다.[93][94][95]

JS-Git은 Git의 하위 집합을 자바스크립트로 구현한 것입니다.[96]

깃 서버

커밋 디프를 보여주는 Gitweb 인터페이스의 스크린샷

깃은 분산형 버전 제어 시스템이기 때문에 서버로 바로 사용할 수 있습니다.명령어가 내장되어 발송됩니다.git daemonGit 프로토콜에서 실행되는 간단한 TCP 서버를 시작합니다.[97][98]전용 Git HTTP 서버는 액세스 제어를 추가하고 웹 인터페이스를 통해 Git 저장소의 내용을 표시하며 여러 저장소를 관리함으로써 (다른 기능 중) 도움을 줍니다.이미 존재하는 Git 저장소를 복제하고 공유하여 다른 사람이 중앙 집중식 저장소로 사용할 수 있습니다.Git 소프트웨어를 설치하고 사용자가 로그인할 수 있게 하는 것만으로 원격 셸을 통해 접근할 수도 있습니다.[99]깃 서버는 일반적으로 TCP 포트 9418에서 청취합니다.[100]

오픈소스

  • 깃 [101]바이너리를 이용한 깃 서버 호스팅
  • Gerrit는 코드 검토를 지원하고 ssh, 통합 Apache MINA 또는 OpenSSH 또는 통합 Jetty 웹 서버를 통해 액세스할 수 있도록 구성할 수 있는 Git 서버입니다.Gerrit은 LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, X509 https 클라이언트 인증서에 대한 통합 기능을 제공합니다.Gerrit 3.0을 사용하면 모든 구성이 Git 저장소로 저장되며 데이터베이스를 실행할 필요가 없습니다.게릿은 핵심에 풀 리퀘스트 기능을 구현했지만 GUI가 부족합니다.
  • Facebook의 파생상품인 Fabricator.페이스북은 머큐리얼을 주로 사용하기 때문에 깃 지원은 그다지 두드러지지 않습니다.[102]
  • AGPLv3 라이센스를 통해 Git, Mercurial 및 Subversion을 지원하는 로드 코드 커뮤니티 에디션(CE).
  • Kalithea는 Git와 Mercurial을 모두 지원하며 Python에서 GPL 라이선스로 개발되었습니다.
  • Git 소프트웨어 위에 스크립트를 제공하여 세분화된 액세스 제어를 제공하는 Gitolite와 같은 외부 프로젝트.[103]
  • 자체 호스팅을 위한 몇 가지 다른 FLOSS 솔루션이 있는데, 여기에는 Gogs와[104] Gitea라는 Gogs의 한 갈래가 포함되며 둘 다 MIT 라이선스를 받아 바둑 언어로 개발되었습니다.

서비스형 Git 서버

참고 항목:소스-코드 호스팅 설비 비교

서비스형 Git 저장소에는 여러 가지 제공 사항이 있습니다.가장 인기 있는 것은 GitHub, SourceForge, Bitbucket, GitLab 등입니다.[37][17][18][19][20]

입양

The Eclipse Foundation은 연례 커뮤니티 조사에서 2014년 5월 현재 Git가 가장 널리 사용되는 소스 코드 관리 도구이며, 2013년 36.3%, 2012년 32% 또는 GitHub 사용을 제외한 Git 응답의 경우 42.9%가 Git를 주요 소스-제어 시스템으로[105] 사용한다고 보고했습니다.2014년 3%, 2013년 30.3%, 2012년 27.6%, 2011년 12.8%입니다.[106]오픈 소스 디렉토리 블랙 덕 오픈 허브는 오픈 소스 프로젝트 간에 유사한 이해를 보고합니다.[107]

스택 오버플로는 2015년 연간 개발자 설문조사(16,694명 응답), 2017년(30,[109][110][111]730명 응답), 2018년(74,298명 응답), 2022년(71,379명 응답)에[108] 버전 제어 기능을 포함시켰습니다.[15]Git는 2022년에 93.9%까지 올랐다고 보고하면서 이러한 설문조사에서 응답 개발자들이 압도적으로 선호하는 것으로 나타났습니다.

응답 개발자가 사용하는 버전 제어 시스템:

이름. 2015 2017 2018 2022
깃 69.3% 69.2% 87.2% 93.9%
전복 36.9% 9.1% 16.1% 5.2%
TFVC 12.2% 7.3% 10.9% [ii]
수은 7.9% 1.9% 3.6% 1.1%
CVS 4.2% [ii] [ii] [ii]
퍼포스 3.3% [ii] [ii] [ii]
VSS [ii] 0.6% [ii] [ii]
클리어케이스 [ii] 0.4% [ii] [ii]
Zip 파일 백업 [ii] 2.0% 7.9% [ii]
원시 네트워크 공유 [ii] 1.7% 7.9% [ii]
다른. 5.8% 3.0% [ii] [ii]
없음. 9.3% 4.8% 4.8% 4.3%

영국 IT 직무 웹사이트 itjobswatch.co.uk 에 따르면 2016년 9월 말 현재 영국의 영구 소프트웨어 개발 직무 중 29.27%가 Git를 인용했으며, 이는 Microsoft Team Foundation Server 12.17%, Subversion 10.60%, Mercurial 1.30%, Visual SourceSafe 0.48%를 앞섰습니다.

확장자

Git Hub 커뮤니티에서 Git에 대한 확장으로 시작하여 현재는 다른 저장소에서 널리 사용되는 Git LFS와 같은 많은 Git 확장이 있습니다.확장자는 보통 서로 다른 사람들에 의해 독립적으로 개발되고 유지되지만, 미래의 어느 시점에는 널리 사용되는 확장자가 Git과 병합될 수 있습니다.

기타 오픈 소스 Git 확장 기능은 다음과 같습니다.

마이크로소프트는 2017년 Perforce에서 마이그레이션할 때 Windows 소스 코드 트리의 크기를 처리하기 위해 VFS(Virtual File System for Git; 이전에는 Git Virtual File System 또는 GVFS) 확장을 개발했습니다.VFS for Git를 사용하면 복제된 저장소에서 파일에 액세스할 때만 콘텐츠가 다운로드되는 플레이스홀더를 사용할 수 있습니다.[117]

관습

깃은 사용 방법에 많은 제한을 두지 않지만, 역사를 정리하기 위해 일부 규약을 채택하고 있으며, 특히 많은 기여자들의 협력이 필요합니다.

  • 마스터 분기는 기본적으로 git init으로 생성되며 다른 변경 사항이 병합되는 분기로 사용되는 경우가 많습니다.[119]따라서 업스트림 원격의 기본 이름은 origin이므로[120] 기본 원격 분기 이름은 origin/master입니다.기본 분기 이름으로 마스터를 사용하는 것은 보편적으로 사실이 아닙니다. GitHub 및 GitLab에서 만든 리포지토리는 마스터 대신 주 분기로 초기화되지만 기본값은 사용자가 변경할 수 있습니다.[121][122]
  • 푸시된 커밋은 일반적으로 덮어쓰지 않고 되돌려야[123] 합니다(커밋은 위에서 수행되며 변경 내용을 이전 커밋으로 되돌립니다).이렇게 하면 공유 커밋을 기반으로 하는 공유 새 커밋이 원격에 존재하지 않기 때문에 해당 커밋이 무효가 되는 것을 방지할 수 있습니다.커밋에 중요한 정보가 포함되어 있는 경우 해당 커밋을 제거해야 하며, 이를 위해서는 기록을 다시 쓰는 보다 복잡한 절차가 필요합니다.
  • git-flow[124] 워크플로우 및 명명 규칙은 종종 기능별 불안정 이력(feature/*), 불안정 공유 이력(develop), 운영 준비 이력(메인), 출시 제품에 대한 긴급 패치(hotfix)를 구분하기 위해 채택됩니다.
  • 꺼내기 요청은 git의 기능이 아니라 git 클라우드 서비스에서 일반적으로 제공됩니다.꺼내기 요청은 한 사용자가 저장소 포크의 분기를 동일한 기록(업스트림 원격이라고 함)을 공유하는 다른 저장소로 병합하는 요청입니다.[125][126]풀 요청의 기본 기능은 저장소의 관리자가 다른 원격(풀 요청의 원본인 저장소)에서 변경 사항을 꺼내는 기능과 다르지 않습니다.그러나 풀 요청 자체는 이러한 작업을 수행하기 위한 스크립트를 시작하는 호스팅 서버에서 관리하는 티켓이며, git SCM의 기능은 아닙니다.

보안.

Git는 액세스 제어 메커니즘을 제공하지 않지만 액세스 제어를 전문으로 하는 다른 도구와 함께 작동하도록 설계되었습니다.[127]

2014년 12월 17일, Git 클라이언트의 윈도우 및 macOS 버전에 영향을 주는 공격이 발견되었습니다.공격자는 .git(저장소의 모든 데이터를 저장하는 Git 저장소의 디렉토리)라는 이름의 악의적인 Git 트리(디렉토리)를 다른 경우에 생성하여 Git가 설치된 대상 컴퓨터에서 임의 코드 실행을 수행할 수 있습니다.공격자가 만든 저장소 또는 공격자가 수정할 수 있는 저장소에 있는 .git/hooks 하위 디렉터리(Git이 실행하는 실행 파일이 있는 폴더)에 악성 파일이 있는 .git의 전 소문자 버전을 수동으로 생성할 수 없기 때문에 필요합니다.Windows 또는 Mac 사용자가 악의적인 디렉토리가 있는 저장소의 버전을 끌어다가(다운로드) 해당 디렉토리로 전환하면 Windows 및 Mac 파일 시스템의 대소문자 구분 특성으로 인해 .git 디렉토리가 덮어쓰게 되고 .git/hooks의 악의적인 실행 파일이 실행될 수 있습니다.공격자의 명령이 실행되는 결과를 초래합니다.공격자는 .git/config 구성 파일을 수정할 수도 있는데, 이 파일을 통해 공격자는 악의적인 Git 별칭(Git 명령 또는 외부 명령의 별칭)을 만들거나 기존 별칭을 수정하여 실행할 수 있습니다.이 취약성은 2014년 12월 17일에 출시된 Git 2.2.1 버전에서 패치되어 다음 날 발표되었습니다.[128][129]

2015년 9월 29일에 출시된 Git 버전 2.6.1에는 보안 취약점(CVE-)을 위한 패치가 포함되어 있습니다.임의의 코드 실행을 허용한 2015-7545).[130][131]이 취약성은 공격자가 공격 대상자에게 특정 URL을 복제하도록 유인할 수 있는 경우로, URL 자체에 임의 명령이 포함되어 있기 때문입니다.[132]공격자는 연결 암호화가 해제된 경우 중간자 공격을 통해 이 공격을 사용할 수 있으며,[132] 이로 인해 사용자가 선택한 URL로 리디렉션될 수 있습니다.저장소의 컨트롤러가 gitmodules 파일을 통해 임의 URL을 지정할 수 있으므로 재귀 클론도 취약했습니다.[132]

깃은 내부적으로 SHA-1 해시를 사용합니다.Linus Torvalds는 이 해시가 대부분 우발적인 부패로부터 보호하기 위한 것이며, 암호학적으로 안전한 해시가 제공하는 보안은 우발적인 부작용일 뿐이며, 주요 보안은 다른 곳에서 서명하는 것이라고 응답했습니다.[133][134]2017년 git에 대한 SHATtered 공격의 시연 이후, git는 이 공격에 저항하는 SHA-1 변형을 사용하도록 수정되었습니다.2020년 2월부터 해시 함수 전환 계획을 수립 중입니다.[135]

상표

"Git"은 2015-02-03 이후 US500000085961336에 따른 Software Freedom Conservancy의 등록 단어 상표입니다.

참고 항목

메모들

  1. ^ 2005-04-11 이후로 GPL-2.0만.LGPLv2.1과 같이 호환되는 라이센스를 받는 일부 부품.[6]
  2. ^ a b c d e f g h i j k l m n o p q r s 이 설문조사에서 옵션으로 나열되지 않음

인용문

  1. ^ "Initial revision of "git", the information manager from hell". GitHub. 8 April 2005. Archived from the original on 16 November 2015. Retrieved 20 December 2015.
  2. ^ "Commit Graph". GitHub. 8 June 2016. Archived from the original on 20 January 2016. Retrieved 19 December 2015.
  3. ^ Junio C Hamano (21 August 2023). "[ANNOUNCE] Git v2.42.0". Retrieved 22 August 2023.
  4. ^ "Git website". Archived from the original on 9 June 2022. Retrieved 9 June 2022.
  5. ^ "Git Source Code Mirror". GitHub. Archived from the original on 3 June 2022. Retrieved 9 June 2022.
  6. ^ "Git's LGPL license at github.com". GitHub. 20 May 2011. Archived from the original on 11 April 2016. Retrieved 12 October 2014.
  7. ^ "Git's GPL license at github.com". GitHub. 18 January 2010. Archived from the original on 11 April 2016. Retrieved 12 October 2014.
  8. ^ "Tech Talk: Linus Torvalds on git (at 00:01:30)". Archived from the original on 20 December 2015. Retrieved 20 July 2014 – via YouTube.
  9. ^ Chacon & Straub 2014, pp. 29-31
  10. ^ a b Torvalds, Linus (7 April 2005). "Re: Kernel SCM saga." linux-kernel (Mailing list). Archived from the original on 1 July 2019. Retrieved 3 February 2017. "그래서 저는 훨씬 더 빨리 상황을 추적하기 위해 몇 가지 대본을 쓰고 있습니다."
  11. ^ a b Torvalds, Linus (10 June 2007). "Re: fatal: serious inflate inconsistency". git (Mailing list).
  12. ^ a b c d Linus Torvalds (3 May 2007). Google tech talk: Linus Torvalds on git. Event occurs at 02:30. Archived from the original on 28 May 2007. Retrieved 16 May 2007.
  13. ^ "A Short History of Git". Pro Git (2nd ed.). Apress. 2014. Archived from the original on 25 December 2015. Retrieved 26 December 2015.
  14. ^ Chacon, Scott (24 December 2014). Pro Git (2nd ed.). New York, NY: Apress. pp. 29–30. ISBN 978-1-4842-0077-3. Archived from the original on 25 December 2015.
  15. ^ a b "Stack Overflow Developer Survey 2022". Stack Overflow. Retrieved 4 August 2022.
  16. ^ Krill, Paul (28 September 2016). "Enterprise repo wars: GitHub vs. GitLab vs. Bitbucket". InfoWorld. Retrieved 2 February 2020.
  17. ^ a b "github.com Competitive Analysis, Marketing Mix and Traffic". Alexa. Archived from the original on 31 March 2013. Retrieved 2 February 2020.
  18. ^ a b "sourceforge.net Competitive Analysis, Marketing Mix and Traffic". Alexa. Archived from the original on 20 October 2020. Retrieved 2 February 2020.
  19. ^ a b "bitbucket.org Competitive Analysis, Marketing Mix and Traffic". Alexa. Archived from the original on 23 June 2017. Retrieved 2 February 2020.
  20. ^ a b "gitlab.com Competitive Analysis, Marketing Mix and Traffic". Alexa. Archived from the original on 30 November 2017. Retrieved 2 February 2020.
  21. ^ Brown, Zack (27 July 2018). "A Git Origin Story". Linux Journal. Linux Journal. Archived from the original on 13 April 2020. Retrieved 28 May 2020.
  22. ^ "BitKeeper and Linux: The end of the road?". Linux.com. 11 April 2005. Retrieved 18 May 2023.
  23. ^ McAllister, Neil (2 May 2005). "Linus Torvalds' BitKeeper blunder". InfoWorld. Archived from the original on 26 August 2015. Retrieved 8 September 2015.
  24. ^ a b Torvalds, Linus (27 February 2007). "Re: Trivia: When did git self-host?". git (Mailing list).
  25. ^ Torvalds, Linus (6 April 2005). "Kernel SCM saga." linux-kernel (Mailing list).
  26. ^ Torvalds, Linus (17 April 2005). "First ever real kernel git merge!". git (Mailing list).
  27. ^ Mackall, Matt (29 April 2005). "Mercurial 0.4b vs git patchbomb benchmark". git (Mailing list).
  28. ^ Torvalds, Linus (17 June 2005). "Linux 2.6.12". git-commits-head (Mailing list).
  29. ^ Torvalds, Linus (27 July 2005). "Meet the new maintainer..." git (Mailing list).
  30. ^ Hamano, Junio C. (21 December 2005). "Announce: Git 1.0.0". git (Mailing list).
  31. ^ "GitFaq: Why the 'Git' name?". Git.or.cz. Archived from the original on 23 July 2012. Retrieved 14 July 2012.
  32. ^ "After controversy, Torvalds begins work on 'git'". PC World. 14 July 2012. Archived from the original on 1 February 2011. Torvalds seemed aware that his decision to drop BitKeeper would also be controversial. When asked why he called the new software, 'git', British slang meaning 'a rotten person', he said. 'I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.'
  33. ^ "git(1) Manual Page". Archived from the original on 21 June 2012. Retrieved 21 July 2012.
  34. ^ "Initial revision of 'git', the information manager from hell · git/git@e83c516". GitHub. Archived from the original on 8 October 2017. Retrieved 21 January 2016.
  35. ^ "Tags". GitHub. Archived from the original on 29 September 2021. Retrieved 28 January 2022.
  36. ^ "Highlights from Git 2.25". The GitHub Blog. 13 January 2020. Archived from the original on 22 March 2021. Retrieved 27 November 2020. A sparse checkout is nothing more than a list of file path patterns that Git should attempt to populate in your working copy when checking out the contents of your repository. Effectively, it works like a .gitignore, except it acts on the contents of your working copy, rather than on your index.
  37. ^ a b "Highlights from Git 2.26". The GitHub Blog. 22 March 2020. Archived from the original on 22 March 2021. Retrieved 25 November 2020. You may remember when Git introduced a new version of its network fetch protocol way back in 2018. That protocol is now used by default in 2.26, so let's refresh ourselves on what that means. The biggest problem with the old protocol is that the server would immediately list all of the branches, tags, and other references in the repository before the client had a chance to send anything. For some repositories, this could mean sending megabytes of extra data, when the client really only wanted to know about the master branch. The new protocol starts with the client request and provides a way for the client to tell the server which references it's interested in. Fetching a single branch will only ask about that branch, while most clones will only ask about branches and tags. This might seem like everything, but server repositories may store other references (such as the head of every pull request opened in the repository since its creation). Now, fetches from large repositories improve in speed, especially when the fetch itself is small, which makes the cost of the initial reference advertisement more expensive relatively speaking. And the best part is that you won't need to do anything! Due to some clever design, any client that speaks the new protocol can work seamlessly with both old and new servers, falling back to the original protocol if the server doesn't support it. The only reason for the delay between introducing the protocol and making it the default was to let early adopters discover any bugs.
  38. ^ "Highlights from Git 2.28". The GitHub Blog. 27 July 2020. Archived from the original on 22 March 2021. Retrieved 25 November 2020.
  39. ^ "Highlights from Git 2.29". The GitHub Blog. 19 October 2020. Archived from the original on 22 March 2021. Retrieved 25 November 2020.
  40. ^ "Git 2.30 Release Notes". Git Downloads. 27 December 2020. Archived from the original on 22 March 2021. Retrieved 27 December 2020.
  41. ^ "Git 2.31 Release Notes". Git Downloads. 3 April 2021. Retrieved 3 April 2021.
  42. ^ "Highlights from Git 2.31". The GitHub Blog. 15 March 2021. Retrieved 2 July 2021.
  43. ^ "git/git". GitHub. Archived from the original on 8 February 2017. Retrieved 1 December 2011.
  44. ^ Hamano, Junio (21 November 2007). "How to maintain Git". GitHub. Archived from the original on 22 March 2021. Retrieved 1 August 2020.
  45. ^ Torvalds, Linus (5 May 2006). "Re: [ANNOUNCE] Git wiki". linux-kernel (Mailing list). 깃의 전임자들에 대한 "어떤 역사적 배경"
  46. ^ a b Torvalds, Linus (8 April 2005). "Re: Kernel SCM saga". linux-kernel (Mailing list). Archived from the original on 22 March 2021. Retrieved 20 February 2008.
  47. ^ a b Torvalds, Linus (23 March 2006). "Re: Errors GITtifying GCC and Binutils". git (Mailing list). Archived from the original on 22 March 2021. Retrieved 3 February 2017.
  48. ^ Torvalds, Linus (20 October 2006). "Re: VCS comparison table". git (Mailing list). Archived from the original on 22 March 2021. Retrieved 3 February 2017. Git vs.비트키퍼.
  49. ^ "Git – A Short History of Git". git-scm.com. Archived from the original on 22 March 2021. Retrieved 15 June 2020.
  50. ^ "Git – Distributed Workflows". git-scm.com. Archived from the original on 22 October 2014. Retrieved 15 June 2020.
  51. ^ Gunjal, Siddhesh (19 July 2019). "What is Version Control Tool? Explore Git and GitHub". Medium. Retrieved 25 October 2020.
  52. ^ Torvalds, Linus (19 October 2006). "Re: VCS comparison table". git (Mailing list).
  53. ^ Jst의 모질라진 블로그
  54. ^ Dreier, Roland (13 November 2006). "Oh what a relief it is". Archived from the original on 16 January 2009.git log가 svn log보다 100배 빠르다는 것을 관찰하는 것은 git log가 원격 서버에 연락해야 하기 때문입니다.
  55. ^ "Trust". Git Concepts. Git User's Manual. 18 October 2006. Archived from the original on 22 February 2017.
  56. ^ Torvalds, Linus. "Re: VCS comparison table". git (Mailing list). Retrieved 10 April 2009.Git의 스크립트 지향 디자인을 Torvalds, Linus. "Re: VCS comparison table". git (Mailing list). Retrieved 10 April 2009.설명하기
  57. ^ iabervon (22 December 2005). "Git rocks!". Archived from the original on 14 September 2016.Git의 스크립트 능력을 iabervon (22 December 2005). "Git rocks!". Archived from the original on 14 September 2016.칭찬합니다.
  58. ^ "Git – Git SCM Wiki". git.wiki.kernel.org. Retrieved 25 October 2020.
  59. ^ Chacon & Straub 2014.
  60. ^ "Git User's Manual". 10 March 2020. Archived from the original on 10 May 2020.
  61. ^ Chacon & Straub 2014, 페이지 499.
  62. ^ Chacon & Straub 2014, 페이지 33-34
  63. ^ a b "Git – Packfiles". git-scm.com.
  64. ^ Chacon & Straub 2014, 페이지 568.
  65. ^ Torvalds, Linus (10 April 2005). "Re: more git updates." linux-kernel (Mailing list).
  66. ^ Haible, Bruno (11 February 2007). "how to speed up 'git log'?". git (Mailing list).
  67. ^ Torvalds, Linus (1 March 2006). "Re: impure renames / history tracking". git (Mailing list).
  68. ^ Hamano, Junio C. (24 March 2006). "Re: Errors GITtifying GCC and Binutils". git (Mailing list).
  69. ^ Hamano, Junio C. (23 March 2006). "Re: Errors GITtifying GCC and Binutils". git (Mailing list).
  70. ^ Torvalds, Linus (28 November 2006). "Re: git and bzr". git (Mailing list).Torvalds, Linus (28 November 2006). "Re: git and bzr". git (Mailing list).사용시git-blame소스 파일 간에 이동된 코드를 보여줍니다.
  71. ^ Torvalds, Linus (18 July 2007). "git-merge(1)". Archived from the original on 16 July 2016.
  72. ^ Torvalds, Linus (18 July 2007). "CrissCrossMerge". Archived from the original on 13 January 2006.
  73. ^ Torvalds, Linus (10 April 2005). "Re: more git updates..." linux-kernel (Mailing list).
  74. ^ "Git – Git Objects". git-scm.com.
  75. ^ 일부 깃 내부가
  76. ^ a b Chacon & Straub 2014, pp. 81–83.
  77. ^ Chacon & Straub 2014, 페이지 485-488
  78. ^ Chacon & Straub 2014, 페이지 488-490
  79. ^ Chacon & Straub 2014, 페이지 495-496
  80. ^ Chacon & Straub 2014, pp. 497–501.
  81. ^ "Git – Git References". git-scm.com.
  82. ^ "Project Configuration File Format". Gerrit Code Review. Archived from the original on 3 December 2020. Retrieved 2 February 2020.
  83. ^ "downloads". Archived from the original on 8 May 2012. Retrieved 14 May 2012.
  84. ^ "git package versions – Repology". Archived from the original on 19 January 2022. Retrieved 30 November 2021.
  85. ^ "msysGit". GitHub. Archived from the original on 10 October 2016. Retrieved 20 September 2016.
  86. ^ "Git – Downloading Package". git-scm.com. (소스 코드)
  87. ^ "JGit". Archived from the original on 31 August 2012. Retrieved 24 August 2012.
  88. ^ "Git – go-git". git-scm.com. Retrieved 19 April 2019.
  89. ^ "SQL interface to Git repositories, written in Go.", github.com, retrieved 19 April 2019
  90. ^ "Keybase launches encrypted git". keybase.io. Retrieved 19 April 2019.
  91. ^ "Dulwich". Archived from the original on 29 May 2012. Retrieved 27 August 2012.
  92. ^ "libgit2". GitHub. Archived from the original on 11 April 2016. Retrieved 24 August 2012.
  93. ^ "rugged". GitHub. Archived from the original on 24 July 2013. Retrieved 24 August 2012.
  94. ^ "pygit2". GitHub. Archived from the original on 5 August 2015. Retrieved 24 August 2012.
  95. ^ "hlibgit2". Archived from the original on 25 May 2013. Retrieved 30 April 2013.
  96. ^ "js-git: a JavaScript implementation of Git". GitHub. Archived from the original on 7 August 2013. Retrieved 13 August 2013.
  97. ^ Chacon & Straub 2014, 페이지 138-139
  98. ^ "Git – Git Daemon". git-scm.com. Retrieved 10 July 2019.
  99. ^ 4.4 Git on the Server – 2014년 10월 22일 Wayback Machine, Pro Git에서 서버 아카이브 설정
  100. ^ "1.4 Getting Started – Installing Git". git-scm.com. Archived from the original on 2 November 2013. Retrieved 1 November 2013.
  101. ^ Chacon, Scott; Straub, Ben (2014). "Git on the Server – Setting Up the Server". Pro Git (2nd ed.). Apress. ISBN 978-1484200773.
  102. ^ 확산 사용자 안내: 저장소 호스팅 2020년 9월 20일 웨이백 머신에서 보관.
  103. ^ "Gitolite: Hosting Git Repositories".
  104. ^ "Gogs: A painless self-hosted Git service".
  105. ^ "Eclipse Community Survey 2014 results Ian Skerrett". Ianskerrett.wordpress.com. 23 June 2014. Archived from the original on 25 June 2014. Retrieved 23 June 2014.
  106. ^ "Results of Eclipse Community Survey 2012". eclipse.org. Archived from the original on 11 April 2016.
  107. ^ "Compare Repositories – Open Hub". Archived from the original on 7 September 2014.
  108. ^ "Stack Overflow Annual Developer Survey". Stack Exchange, Inc. Retrieved 9 January 2020. Stack Overflow's annual Developer Survey is the largest and most comprehensive survey of people who code around the world. Each year, we field a survey covering everything from developers' favorite technologies to their job preferences. This year marks the ninth year we've published our annual Developer Survey results, and nearly 90,000 developers took the 20-minute survey earlier this year.
  109. ^ "Stack Overflow Developer Survey 2015". Stack Overflow. Archived from the original on 4 May 2019. Retrieved 29 May 2019.
  110. ^ "Stack Overflow Developer Survey 2017". Stack Overflow. Archived from the original on 29 May 2019. Retrieved 29 May 2019.
  111. ^ "Stack Overflow Developer Survey 2018". Stack Overflow. Archived from the original on 30 May 2019. Retrieved 29 May 2019.
  112. ^ "Git (software) Jobs, Average Salary for Git Distributed Version Control System Skills". Itjobswatch.co.uk. Archived from the original on 8 October 2016. Retrieved 30 September 2016.
  113. ^ "Team Foundation Server Jobs, Average Salary for Microsoft Team Foundation Server (TFS) Skills". Itjobswatch.co.uk. Archived from the original on 29 October 2016. Retrieved 30 September 2016.
  114. ^ "Subversion Jobs, Average Salary for Apache Subversion (SVN) Skills". Itjobswatch.co.uk. Archived from the original on 25 October 2016. Retrieved 30 September 2016.
  115. ^ "Mercurial Jobs, Average Salary for Mercurial Skills". Itjobswatch.co.uk. Archived from the original on 23 September 2016. Retrieved 30 September 2016.
  116. ^ "VSS/SourceSafe Jobs, Average Salary for Microsoft Visual SourceSafe (VSS) Skills". Itjobswatch.co.uk. Archived from the original on 29 October 2016. Retrieved 30 September 2016.
  117. ^ "Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day". Ars Technica. 24 May 2017. Archived from the original on 24 May 2017. Retrieved 24 May 2017.
  118. ^ "git-init". Git. Archived from the original on 15 March 2022.
  119. ^ "Git – Branches in a Nutshell". git-scm.com. Archived from the original on 20 December 2020. Retrieved 15 June 2020. The "master" branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the git init command creates it by default and most people don't bother to change it.
  120. ^ Chacon & Straub 2014, 페이지 103–109
  121. ^ github/renaming, GitHub, 4 December 2020, retrieved 4 December 2020
  122. ^ Default branch name for new repositories now main, GitLab, 22 June 2021, retrieved 22 June 2021
  123. ^ "Git Revert Atlassian Git Tutorial". Atlassian. Reverting has two important advantages over resetting. First, it doesn't change the project history, which makes it a "safe" operation for commits that have already been published to a shared repository.
  124. ^ "Gitflow Workflow Atlassian Git Tutorial". Atlassian. Retrieved 15 June 2020.
  125. ^ Chacon & Straub 2014, 페이지 170-174
  126. ^ "Forking Workflow Atlassian Git Tutorial". Atlassian. Retrieved 15 June 2020.
  127. ^ "Git repository access control". Archived from the original on 14 September 2016. Retrieved 6 September 2016.
  128. ^ Pettersen, Tim (20 December 2014). "Securing your Git server against CVE-2014-9390". Archived from the original on 24 December 2014. Retrieved 22 December 2014.
  129. ^ Hamano, J. C. (18 December 2014). "[Announce] Git v2.2.1 (and updates to older maintenance tracks)". Newsgroup: gmane.linux.kernel. Archived from the original on 19 December 2014. Retrieved 22 December 2014.
  130. ^ "CVE-2015-7545". 15 December 2015. Archived from the original on 26 December 2015. Retrieved 26 December 2015.
  131. ^ "Git 2.6.1". GitHub. 29 September 2015. Archived from the original on 11 April 2016. Retrieved 26 December 2015.
  132. ^ a b c Blake Burkhart; et al. (5 October 2015). "Re: CVE Request: git". Archived from the original on 27 December 2015. Retrieved 26 December 2015.
  133. ^ "hash – How safe are signed git tags? Only as safe as SHA-1 or somehow safer?". Information Security Stack Exchange. 22 September 2014. Archived from the original on 24 June 2016.
  134. ^ "Why does Git use a cryptographic hash function?". Stack Overflow. 1 March 2015. Archived from the original on 1 July 2016.
  135. ^ "Git – hash-function-transition Documentation". git-scm.com.

참고문헌

외부 링크

위키미디어 커먼즈에는 깃과 관련된 미디어가 있습니다.
Wikibooks는 다음을 주제로 한 책을 가지고 있습니다: Git