본문으로 이동

깃 (소프트웨어)

위키백과, 우리 모두의 백과사전.
깃
Git
원저자리누스 토르발스[1]
개발자하마노 주니오 외 다수[2]
발표일2005년 4월 7일(21년 전)(2005-04-07)
안정화 버전
2.56.0[3] 위키데이터에서 편집하기 / 2026년 9월 28일
저장소
프로그래밍 언어주로 C로 작성되었으며, GUI와 프로그래밍 스크립트는 셸 스크립트, 펄, Tcl 및 파이썬으로 작성되었다.[4][5]
운영 체제POSIX (리눅스, macOS, Solaris, AIX), 윈도우
언어영어
종류버전 관리
라이선스GPL-2.0-only[i][7]
웹사이트git-scm.com 위키데이터에서 편집하기

깃(Git, Listeni/ɡɪt/[8])은 소스 코드나 데이터의 버전을 관리할 수 있는 분산 버전 관리 소프트웨어 시스템이다.[9] 협업을 통해 소프트웨어를 개발하는 프로그래머들이 소스 코드를 관리하기 위해 주로 사용한다.

깃의 설계 목표에는 속도, 데이터 무결성, 그리고 수천 개의 병렬 브랜치가 서로 다른 컴퓨터에서 실행되는 분산 비선형 워크플로 지원 등이 포함된다.[10][11][12]

대부분의 다른 분산 버전 관리 시스템과 마찬가지로, 그리고 대부분의 클라이언트-서버 시스템과 달리 깃은 네트워크 접속이나 중앙 서버와 무관하게 이력과 버전 추적 능력을 갖춘 전체 저장소(일명 "레포")의 로컬 사본을 유지한다. 저장소는 버전 관리 기능을 제공하기 위한 추가적인 숨김 파일과 함께 각 컴퓨터의 표준 디렉토리에 저장된다.[13] 깃은 이력을 공유하는 저장소들 간에 변경 사항을 동기화하는 기능을 제공하며, 비동기적 협업을 위해 원격 머신의 저장소까지 이를 확장할 수 있다. 동일한 이력을 가진 모든 저장소는 대등한 관계이지만, 개발자들은 종종 통합된 사본을 보관하기 위해 중앙 서버를 사용하여 저장소를 호스팅한다.

깃은 GPL-2.0-only 라이선스 하에 공유되는 자유-오픈 소스 소프트웨어이다.

깃은 원래 리누스 토르발스가 리눅스 커널 개발의 버전 관리를 위해 만들었다.[14] "Git" 상표는 소프트웨어 자유 단체에 의해 등록되어 있다.

오늘날 깃은 소프트웨어 개발자들이 가장 흔히 사용하는 버전 관리 시스템이다. 가장 인기 있는 분산 버전 관리 시스템이며,[15][16] 2022년 기준으로 개발자의 거의 95%가 깃을 주 버전 관리 시스템으로 사용한다고 답했다.[17] 이는 전문 개발자들 사이에서 가장 널리 사용되는 소스 코드 관리 도구이다. 깃허브, 소스포지, 빗버킷, 깃랩을 포함한 다양한 깃 저장소 서비스가 제공되고 있다.[18][19][20][21][22]

역사

[편집]

리누스 토르발스는 2002년부터 리눅스 커널 개발에 사용되던 사유 소스 코드 관리(SCM) 시스템인 비트키퍼의 자유 라이선스가 취소된 후, 2005년 4월에 깃 개발을 시작했다.[23][24] 비트키퍼의 저작권자인 래리 맥보이는 앤드루 트리젤이 비트키퍼 통신 프로토콜을 역공학하여 SourcePuller를 만들었다고 주장했다.[25] 이 사건은 또 다른 버전 관리 시스템인 머큐리얼의 탄생을 촉발하기도 했다.

리누스 토르발스는 비트키퍼처럼 사용할 수 있는 분산 시스템을 원했지만, 당시 사용 가능한 자유 시스템 중 어느 것도 그의 필요를 충족하지 못했다. 그는 패치를 적용하고 모든 관련 메타데이터를 업데이트하는 데 30초가 걸리는 소스 코드 관리 시스템의 예를 들며, 동료 관리자들과 동기화하는 데 한 번에 250번의 작업이 필요할 수 있는 리눅스 커널 개발의 요구 사항을 감당할 수 없을 것이라고 지적했다. 설계 기준으로 그는 패치 작업이 3초 이내에 완료되어야 한다고 명시했으며, 세 가지 목표를 추가했다.[10]

  • CVS를 하지 말아야 할 일의 예로 삼을 것. 의심스러우면 정확히 반대로 결정할 것.[12]
  • 비트키퍼와 같은 분산 워크플로를 지원할 것.[12]
  • 실수든 악의적이든 손상에 대비한 매우 강력한 안전장치를 포함할 것.[11]

이러한 기준들은 당시 사용되던 모든 버전 관리 시스템을 배제하게 만들었고, 그래서 리눅스 커널 2.6.12-rc2 개발 릴리스 직후 리누스 토르발스는 직접 시스템을 작성하기 시작했다.[12]

깃의 개발은 2005년 4월 3일에 시작되었다.[26] 리누스 토르발스는 4월 6일에 프로젝트를 발표했고 다음 날 셀프호스팅(self-hosting)이 가능해졌다.[26][27] 여러 브랜치의 첫 번째 머지는 4월 18일에 이루어졌다.[28] 리누스 토르발스는 그의 성능 목표를 달성했다. 4월 29일에 초기 깃은 초당 6.7개의 패치 속도로 리눅스 커널 트리에 패치를 기록하는 벤치마크 결과를 보여주었다.[29] 6월 16일, 깃은 커널 2.6.12 릴리스를 관리하게 되었다.[30]

리누스 토르발스는 2005년 7월 26일, 프로젝트의 주요 기여자였던 하마노 주니오에게 유지보수 권한을 넘겼다.[31] 하마노 주니오는 2005년 12월 21일의 1.0 릴리스를 책임졌다.[32]

명칭

[편집]

리누스 토르발스는 불쾌하거나 어리석은 사람을 뜻하는 영국 영어 속어인 git이라는 이름에 대해 다음과 같이 농담했다. "나는 이기적인 놈이라서 내 모든 프로젝트 이름을 내 이름을 따서 짓는다. 처음에는 '리눅스'였고, 이제는 'git'이다."[33][34] 매뉴얼 페이지는 깃을 "어리석은 콘텐츠 추적자"라고 설명한다.[35]

소스 코드의 리드미 파일에는 더 자세한 설명이 나와 있다.[36]

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

  • 발음하기 쉽고 일반적인 UNIX 명령어에서 실제로 사용되지 않는 임의의 세 글자 조합. "get"의 잘못된 발음이라는 사실은 관련이 있을 수도 있고 없을 수도 있다.
  • 바보. 경멸스럽고 비열한 사람. 단순함. 속어 사전에서 마음에 드는 것을 골라라.
  • "Global information tracker"(전역 정보 추적기): 기분이 좋고 실제로 잘 작동할 때. 천사들이 노래하고 방 안에 갑자기 빛이 가득 찬다.
  • "Goddamn idiotic truckload of sh*t"(빌어먹을 바보 같은 쓰레기 더미): 고장 났을 때.

깃의 소스 코드는 이 프로그램을 "지옥에서 온 정보 관리자"라고 지칭한다.[37][38]

특징

[편집]

설계

[편집]

깃의 설계는 대규모 분산 개발 프로젝트를 관리하면서 얻은 리누스 토르발스의 리눅스 경험과, 동일한 프로젝트에서 얻은 파일 시스템 성능에 대한 해박한 지식, 그리고 단기간에 작동하는 시스템을 만들어야 한다는 절박한 필요성이 결합된 결과물이다. 이러한 영향은 다음과 같은 구현 선택으로 이어졌다.[14]

비선형 개발에 대한 강력한 지원
깃은 빠른 브랜치 생성과 머지를 지원하며, 비선형적인 개발 이력을 시각화하고 탐색하기 위한 전용 도구를 포함한다. 깃에서 핵심적인 가정은 변경 사항이 작성되는 것보다 더 자주 머지될 것이라는 점인데, 이는 변경 사항이 다양한 검토자들에게 전달되기 때문이다. 깃에서 브랜치는 매우 가볍다. 브랜치는 단지 하나의 커밋에 대한 참조일 뿐이다.
분산 개발
머큐리얼, Bazaar, 모노톤 등과 마찬가지로 깃은 각 개발자에게 전체 개발 이력의 로컬 사본을 제공하며, 변경 사항은 한 저장소에서 다른 저장소로 복사된다. 이러한 변경 사항은 추가된 개발 브랜치로 가져오기(import) 되며, 로컬에서 개발된 브랜치와 동일한 방식으로 머지될 수 있다.[39]
기존 시스템 및 프로토콜과의 호환성
저장소는 HTTPS, FTP 또는 일반 소켓이나 ssh를 통한 깃 프로토콜로 게시될 수 있다. 깃은 또한 CVS 서버 에뮬레이션 기능을 갖추고 있어 기존 CVS 클라이언트 및 IDE 플러그인을 사용하여 깃 저장소에 접근할 수 있게 해준다. 아파치 서브버전 저장소는 git-svn을 통해 직접 사용할 수 있다.[40]
대규모 프로젝트의 효율적인 처리
리누스 토르발스는 깃이 매우 빠르고 확장성이 좋다고 설명했으며,[41] 모질라에서 수행한 성능 테스트에 따르면 대규모 저장소에서 Diff를 수행할 때 머큐리얼이나 Bazaar보다 한 자릿수(order of magnitude) 더 빨랐다. 로컬에 저장된 저장소에서 버전 이력을 가져오는 것은 원격 서버에서 가져오는 것보다 100배 더 빠를 수 있다.[42]
이력의 암호학적 인증
깃 이력은 특정 버전의 ID(Git 용어로 커밋)가 해당 커밋에 이르기까지의 전체 개발 이력에 의존하는 방식으로 저장된다. 일단 게시되면 이전 버전을 알아차리지 못하게 변경하는 것은 불가능하다. 이 구조는 머클 트리와 유사하지만 노드와 리프에 데이터가 추가되어 있다.[43] (머큐리얼과 모노톤도 이 속성을 가지고 있다.)
툴킷 기반 설계
깃은 C로 작성된 프로그램 세트와 그 프로그램들을 감싸는 여러 셸 스크립트로 설계되었다.[44] 이후 속도와 이식성을 위해 대부분의 스크립트가 C로 다시 작성되었지만 설계는 유지되어 구성 요소들을 서로 연결하기 쉽다.[45]
플러그형 머지 전략
툴킷 설계의 일환으로 깃은 불완전한 머지에 대해 잘 정의된 모델을 가지고 있으며, 이를 완료하기 위한 여러 알고리즘을 갖추고 있다. 결국 자동 머지를 완료할 수 없어 수동 편집이 필요하다는 것을 사용자에게 알리는 방식으로 마무리된다.[46]
수집 전까지 쌓이는 쓰레기
작업을 중단하거나 변경 사항을 취소하면 데이터베이스에 쓸모없는 객체들이 남게 된다. 이들은 일반적으로 계속 늘어나는 유효 객체 이력의 작은 부분에 불과하다. 깃은 저장소에 일정 수준 이상의 객체들이 생성되면 자동으로 쓰레기 수집을 수행한다. git gc를 사용하여 명시적으로 쓰레기 수집을 호출할 수도 있다.[47][48]
주기적인 명시적 객체 팩킹
깃은 새로 생성된 각 객체를 별도의 파일로 저장한다. 비록 개별적으로 압축되지만 이는 많은 공간을 차지하고 비효율적이다. 이는 팩파일이라 불리는 하나의 파일(또는 네트워크 바이트 스트림) 안에 여러 객체를 델타 부호화 압축하여 저장하는 팩을 사용함으로써 해결된다. 팩은 같은 이름을 가진 파일들이 아마도 비슷할 것이라는 휴리스틱을 사용하여 압축된다. 각 팩파일에 대응하는 인덱스 파일이 생성되어 팩파일 내 각 객체의 오프셋을 기록한다. 주기적인 리팩킹은 공간 효율성을 유지하기 위해 필요하다. 저장소를 팩킹하는 과정은 계산 비용이 많이 들 수 있다. 깃은 객체가 느슨하지만 빠르게 생성된 형식으로 저장소에 존재할 수 있게 함으로써 비용이 많이 드는 팩 작업을 나중으로 미룰 수 있게 해준다. 깃은 주기적으로 자동 리팩킹을 수행하지만 git gc 명령으로 수동 리팩킹도 가능하다.[49] 데이터 무결성을 위해 팩파일과 인덱스 모두 내부에 SHA-1 체크섬을 가지고 있으며,[50] 팩파일의 파일명에도 SHA-1 체크섬이 포함된다. 저장소의 무결성을 확인하려면 git fsck 명령을 실행한다.[51][52]

깃의 또 다른 특징은 파일의 디렉토리 트리를 스냅샷으로 찍는다는 점이다. 소스 코드 버전을 추적하는 초기 시스템인 소스 코드 제어 시스템(SCCS)과 리비전 컨트롤 시스템(RCS)은 개별 파일 단위로 작동했으며, 대부분 유사한 버전들 사이에서 델타 부호화를 통해 얻을 수 있는 공간 절약을 강조했다. 이후의 개정 관리 시스템들도 프로젝트의 여러 개정판에 걸쳐 파일이 고유 정체성을 가진다는 이 개념을 유지했다. 그러나 리누스 토르발스는 이 개념을 거부했다.[53] 결과적으로 깃은 소스 코드 트리 아래의 어떠한 수준에서도 파일 개정 관계를 명시적으로 기록하지 않는다.

단점

[편집]

이러한 암시적 개정 관계는 몇 가지 중요한 결과를 초래한다.

  • 전체 프로젝트보다 개별 파일의 변경 이력을 조사하는 비용이 약간 더 많이 든다.[54] 특정 파일에 영향을 준 변경 이력을 얻으려면 깃은 전체 이력을 훑으며 각 변경 사항이 해당 파일을 수정했는지 확인해야 한다. 하지만 이 방법 덕분에 깃은 임의의 파일 세트에 대한 변경 사항을 보여주는 단일 이력을 동일한 효율로 생성할 수 있다. 예를 들어 소스 트리의 하위 디렉토리와 관련 전역 헤더 파일을 함께 보는 것은 매우 흔한 사례이다.
  • 이름 변경은 명시적이 아니라 암시적으로 처리된다. CVS의 흔한 불만 사항 중 하나는 파일 이름을 사용하여 개정 이력을 식별하기 때문에, 이력을 끊거나 이력 이름을 바꿔서 이력을 부정확하게 만들지 않고는 파일을 이동하거나 이름을 바꾸는 것이 불가능하다는 점이다. CVS 이후의 많은 시스템은 이름이 바뀌어도 유지되는 고유한 장기 이름(아이노드 번호와 유사함)을 파일에 부여하여 이를 해결한다. 깃은 이러한 식별자를 기록하지 않으며, 이것이 장점이라고 주장한다.[55][56] 소스 코드 파일은 때때로 쪼개지거나 합쳐지며, 또는 단순히 이름이 바뀐다.[57] 이를 단순히 이름 변경으로 기록하면 (불변하는) 이력 속에 일어난 일에 대한 부정확한 묘사가 고착될 수 있다. 깃은 스냅샷을 찍을 때 기록하는 대신 스냅샷 이력을 탐색할 때 이름 변경을 감지함으로써 이 문제를 해결한다.[58] 하지만 이로 인해 이력을 검토할 때마다 더 많은 CPU 집약적인 작업이 필요하며, 휴리스틱을 조정하기 위한 여러 옵션이 제공된다. 이 메커니즘이 항상 작동하는 것은 아니다. 때때로 동일한 커밋에서 변경과 함께 이름이 바뀐 파일은 기존 파일의 삭제와 새 파일의 생성으로 읽히기도 한다. 개발자들은 이름 변경과 변경 사항을 별도로 커밋함으로써 이러한 제한을 우회할 수 있다.

머지 전략

[편집]

깃은 여러 머지 전략을 구현하며, 머지 시에 기본값이 아닌 전략을 선택할 수 있다.[59]

  • resolve: 전통적인 3방향 머지 알고리즘.
  • recursive: 하나의 브랜치를 pull하거나 머지할 때의 기본값이며, 3방향 머지 알고리즘의 변형이다.

    3방향 머지에 사용될 수 있는 공통 조상이 둘 이상일 때, 공통 조상들의 머지된 트리를 만들고 그것을 3방향 머지를 위한 참조 트리로 사용한다. 리눅스 2.6 커널 개발 이력에서 가져온 이전 머지 커밋들을 테스트한 결과, 이 방식이 잘못된 머지를 일으키지 않으면서 머지 충돌을 줄여주는 것으로 보고되었다. 또한 이 방식은 이름 변경이 포함된 머지도 감지하고 처리할 수 있다.

    — 리누스 토르발스[60]

  • octopus: 세 개 이상의 헤드를 머지할 때의 기본값이다.

자료 구조

[편집]

깃의 기본 요소들은 본질적으로 소스 코드 관리 시스템이 아니다. 리누스 토르발스는 다음과 같이 설명한다.[61]

여러 면에서 깃을 그냥 파일 시스템으로 볼 수 있다. 깃은 콘텐츠 주소 지정 가능하고 버전 관리 개념이 있지만, 나는 정말 파일 시스템 전문가의 관점에서 문제에 접근하여 이를 설계했다(이봐요, 커널이 내가 하는 일입니다). 그리고 사실 전통적인 SCM 시스템을 만드는 데는 전혀 관심이 없다.

이러한 초기 설계 접근 방식으로부터 깃은 전통적인 SCM에 기대되는 모든 기능을 개발해 왔으며,[62] 대부분의 기능은 필요에 따라 만들어진 후 시간이 지나면서 정교해지고 확장되었다.

Git 버전 관리 시스템의 일부 데이터 흐름 및 저장 수준

깃은 두 가지 자료 구조를 가진다. 작업 디렉토리와 다음 커밋될 개정판에 대한 정보를 캐싱하는 가변 인덱스(스테이지 또는 캐시라고도 함)와, 불변 객체들을 저장하는 객체 데이터베이스이다.

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

객체 저장소는 다섯 가지 유형의 객체를 포함한다.[63][51]

  • blob(블롭)은 파일의 내용이다. 블롭은 고유한 파일명, 타임스탬프 또는 기타 메타데이터를 가지지 않는다(블롭의 내부 이름은 내용의 해시값이다). 깃에서 각 블롭은 파일의 한 버전이며 그 안에 파일 데이터가 들어있다.[64]
  • tree(트리) 객체는 디렉토리에 해당한다. 이는 파일명 리스트를 포함하며,[65] 각 파일명은 유형 비트와 해당 파일, 심볼릭 링크 또는 디렉토리 내용인 블롭이나 트리 객체에 대한 참조를 가진다. 이 객체들은 소스 트리의 스냅샷이다. (전체적으로 이는 머클 트리를 구성하며, 이는 루트 트리에 대한 단일 해시만으로도 수많은 하위 디렉토리와 파일로 이루어진 전체 트리 구조의 정확한 상태를 핀포인트로 지칭하기에 충분하고 실제로 커밋에서 그렇게 사용됨을 의미한다.)
  • commit(커밋) 객체는 트리 객체들을 이력으로 연결한다. 여기에는 (최상위 소스 디렉토리의) 트리 객체 이름, 타임스탬프, 로그 메시지, 그리고 0개 이상의 부모 커밋 객체 이름이 포함된다.[66]
  • tag(태그) 객체는 다른 객체에 대한 참조를 포함하고 해당 객체와 관련된 추가 메타데이터를 가질 수 있는 컨테이너이다. 가장 흔하게는 깃이 추적하는 데이터의 특정 릴리스에 해당하는 커밋 객체의 디지털 서명을 저장하는 데 사용된다.[67]
  • packfile(팩파일) 객체는 소형화 및 네트워크 프로토콜을 통한 전송 용이성을 위해 다양한 다른 객체들을 하나의 Zlib 압축 번들로 모은 것이다.[68]

각 객체는 내용의 SHA-1 해시에 의해 식별된다. 깃은 해시를 계산하고 이 값을 객체의 이름으로 사용한다. 객체는 해시의 처음 두 글자와 일치하는 디렉토리에 보관된다. 해시의 나머지 부분은 해당 객체의 파일명으로 사용된다.

깃은 파일의 각 개정판을 고유한 블롭으로 저장한다. 블롭들 사이의 관계는 트리와 커밋 객체를 조사하여 찾을 수 있다. 새로 추가된 객체는 zlib 압축을 사용하여 전체가 저장된다. 이는 디스크 공간을 빠르게 소모할 수 있으므로, 객체들을 팩으로 묶을 수 있다. 팩은 공간 절약을 위해 델타 부호화 압축을 사용하며, 블롭들을 다른 블롭과의 변경 사항으로 저장한다.

또한 깃은 다양한 커밋의 위치를 나타내기 위해 ref(참조의 약자)라 불리는 레이블을 저장한다. 이들은 참조 데이터베이스에 저장되며 각각 다음과 같다.[69]

  • Heads (브랜치): 이름이 붙은 참조로, 그 위에서 커밋이 이루어지면 자동으로 새 커밋으로 전진한다.
  • HEAD: 커밋을 생성하기 위해 작업 트리와 비교될 예약된 헤드이다.
  • Tags: 브랜치 참조와 비슷하지만 특정 커밋에 고정되어 있다. 이력의 중요한 지점에 레이블을 붙이는 데 사용된다.

명령어

[편집]

깃의 명령줄 인터페이스에서 자주 사용되는 명령어는 다음과 같다.[70][71]

  • git init: 깃 저장소를 생성하는 데 사용된다.
  • git clone [URL]: 외부 URL에서 깃 저장소를 복제하거나 복사한다.
  • git add [파일]: 깃의 작업 디렉토리에 파일을 추가한다(커밋될 준비가 된 파일).
  • git commit -m [커밋 메시지]: 현재 작업 디렉토리의 파일들을 커밋한다(이제 저장소 이력의 일부가 됨).

.gitignore 파일은 깃 저장소에 일반 텍스트 파일로 생성될 수 있다. .gitignore 파일에 나열된 파일들은 깃에 의해 추적되지 않는다.[72]: 3–4  이 기능은 키나 비밀번호가 포함된 파일, 각종 불필요한 파일, 그리고 (깃허브가 업로드를 거부할 정도로) 큰 파일을 무시하는 데 사용될 수 있다.[73]

깃 참조

[편집]

참조되지 않은 깃 데이터베이스의 모든 객체는 쓰레기 수집 명령을 사용하거나 자동으로 정리될 수 있다. 객체는 다른 객체나 명시적 참조에 의해 참조될 수 있다. 깃은 다양한 유형의 참조를 가진다. 참조를 생성, 이동, 삭제하는 명령어는 다양하다. git show-ref는 모든 참조를 나열한다. 일부 유형은 다음과 같다.

  • heads: 로컬 객체를 참조함.
  • remotes: 원격 저장소에 존재하는 객체를 참조함.
  • stash: 아직 커밋되지 않은 객체를 참조함.
  • meta: 예컨대 베어 저장소의 설정, 사용자 권한 등. refs/meta/config 네임스페이스는 사후에 도입되어 게릿 등에서 사용됨.[74]
  • tags: 위 설명 참조.

구현

[편집]
gitg는 GTK+를 사용하는 그래픽 프런트엔드이다.

깃(C로 작성된 주요 구현체)은 주로 리눅스에서 개발되지만, BSD 계열(DragonFly BSD, FreeBSD, NetBSD, OpenBSD), Solaris, macOS, 윈도우 등 대부분의 주요 운영체제도 지원한다.[75][76]

깃의 첫 번째 윈도우 이식 버전은 주로 리눅스 버전을 호스팅하는 리눅스 에뮬레이션 프레임워크였다. 윈도우에 깃을 설치하면 GNU 컴파일러 모음의 Mingw-w64 포트, 펄 5, MSYS2(윈도우용 유닉스 유사 에뮬레이션 환경인 시그윈의 포크) 및 다양한 리눅스 유틸리티와 라이브러리의 윈도우 포트 또는 에뮬레이션이 포함된 Program Files 디렉토리가 생성된다. 현재 깃의 네이티브 윈도우 빌드는 32비트 및 64비트 설치 프로그램으로 배포된다.[77] 깃 공식 웹사이트는 현재도 MSYS2 환경을 사용하여 윈도우용 깃 빌드를 유지하고 있다.[78]

JGit은 순수 자바 소프트웨어 라이브러리로, 모든 자바 애플리케이션에 임베드될 수 있도록 설계되었다. JGit은 게릿 코드 리뷰 도구와 이클립스 IDE용 깃 클라이언트인 EGit에서 사용된다.[79]

Go-git은 순수 Go로 작성된 깃의 오픈 소스 소프트웨어 구현체이다.[80] 현재 깃 코드 저장소를 위한 SQL 인터페이스 제공 프로젝트나[81] 깃을 위한 암호화 제공 등에 사용되고 있다.[82]

Dulwich는 순수 파이썬으로 작성된 깃 구현체로 CPython 3.6 이상 및 Pypy를 지원한다.[83]

libgit2는 의존성이 없는 ANSI C 소프트웨어 라이브러리로 윈도우, 리눅스, macOS, BSD를 포함한 여러 플랫폼에서 빌드될 수 있다.[84] 루비, 파이썬, 하스켈을 포함한 많은 프로그래밍 언어를 위한 바인딩을 가지고 있다.[85][86][87]

JS-Git은 깃의 일부 기능을 구현한 자바스크립트 구현체이다.[88]

Game of Trees는 OpenBSD 프로젝트를 위한 깃의 오픈 소스 구현체이다.[89]

git9은 시스템 네이티브 추상화를 사용하여 플랜 9를 위해 독립적으로 구현된 깃이다.[90][91]

gitoxide는 순수 러스트로 작성된 깃 구현체이다.[92]

깃 서버

[편집]
커밋 Diff를 보여주는 Gitweb 인터페이스의 스크린샷

깃은 분산 버전 관리 시스템이므로 별도의 설정 없이도 서버로 사용될 수 있다. 깃 프로토콜에서 실행되는 단순한 TCP 서버를 시작하는 내장 명령어 git daemon이 함께 제공된다.[93][94] 전용 Git HTTP 서버는 접근 제어 추가, 웹 인터페이스를 통한 깃 저장소 내용 표시, 여러 저장소 관리 등의 기능을 추가로 제공한다. 이미 존재하는 깃 저장소는 다른 사람들이 중앙 저장소로 사용할 수 있도록 복제하고 공유할 수 있다. 깃 소프트웨어가 설치되어 있고 사용자가 로그인할 수만 있다면 원격 셸을 통해서도 접근할 수 있다.[95] 깃 서버는 일반적으로 TCP 포트 9418번을 사용한다.[96]

오픈 소스

[편집]
  • 깃 바이너리를 사용하여 깃 서버 호스팅.[97]
  • 게릿: 코드 리뷰를 지원하도록 설정 가능한 깃 서버로, ssh, 통합 아파치 MINA 또는 OpenSSH, 혹은 통합 제티 웹 서버를 통해 접근을 제공한다. 게릿은 LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, X509 https 클라이언트 인증서 통합을 지원한다. 게릿 3.0부터 모든 설정은 깃 저장소에 저장되며 실행에 데이터베이스가 필요하지 않다. 게릿은 코어에 풀 리퀘스트 기능이 구현되어 있으나 이를 위한 GUI는 부족하다.
  • 파브리케이터: 페이스북에서 분사된 프로젝트. 페이스북이 주로 머큐리얼을 사용하기 때문에 깃 지원은 그렇게 두드러지지 않는다.[98]
  • 로드코드 커뮤니티 에디션(CE): Git, 머큐리얼, 아파치 서브버전을 지원하며 AGPLv3 라이선스를 따른다.
  • Kallithea: 깃과 머큐리얼을 모두 지원하며, 파이썬으로 개발되었고 GPL 라이선스를 따른다.
  • gitolite와 같은 외부 프로젝트: 깃 소프트웨어 위에서 미세한 접근 제어를 가능하게 하는 스크립트를 제공한다.
  • Gogs, Gogs의 포크인 Gitea, 그리고 Gitea의 포크인 Forgejo를 포함하여 자체 호스팅을 위한 여러 FLOSS 솔루션이 있다. Gogs와 그 파생형들은 Go 언어를 사용하여 개발되었다. 세 가지 솔루션 모두 MIT 라이선스 하에 제공된다.

서비스형 깃 서버

[편집]

서비스 형태의 깃 저장소도 많이 제공되고 있다. 가장 인기 있는 것은 깃허브, 소스포지, 빗버킷, 깃랩이다.[99][19][20][21][22]

그래픽 인터페이스

[편집]

깃 GUI 클라이언트는 깃 저장소와의 상호작용을 단순화하기 위해 그래픽 사용자 인터페이스를 제공한다.

이러한 GUI들은 브랜치, 커밋, 파일 변경 사항을 포함한 프로젝트 이력을 시각적으로 표현해 준다. 또한 변경 사항 스테이징, 커밋 생성, 브랜치 관리와 같은 작업을 능률적으로 처리해 준다. 시각적 Diff 도구는 병렬 개발로 인해 발생하는 머지 충돌을 해결하는 데 도움을 준다.

깃은 Tcl/Tk GUI를 기본적으로 포함하고 있어, 사용자가 커밋 생성 및 수정, 브랜치 생성 및 머지, 원격 저장소와의 상호작용 등의 작업을 수행할 수 있게 해준다.[100]

공식 GUI 외에도 깃과 함께 배포되는 공식 GUI와 유사한 기능을 제공하는 많은 제3자 인터페이스가 존재한다.[101]

GUI 클라이언트는 깃을 배우고 사용하기 쉽게 만들어주어 워크플로 효율성을 높이고 실수를 줄여준다.

채택

[편집]

이클립스 재단은 연례 커뮤니티 설문조사에서 2014년 5월 현재 깃이 가장 널리 사용되는 소스 코드 관리 도구라고 보고했다. 전문 소프트웨어 개발자의 42.9%가 깃을 주 버전 관리 시스템으로 사용한다고 답했는데,[102] 이는 2013년 36.3%, 2012년 32%에서 증가한 수치이다. 깃허브 사용을 제외한 깃 응답 비율은 2014년 33.3%, 2013년 30.3%, 2012년 27.6%, 2011년 12.8%였다.[103] 오픈 소스 디렉토리인 오픈 허브도 오픈 소스 프로젝트들 사이에서 유사한 채택률을 보고하고 있다.[104]

스택 오버플로는 2015년(16,694명 응답),[105] 2017년(30,730명 응답),[106] 2018년(74,298명 응답),[107] 2022년(71,379명 응답)[17] 연례 개발자 설문조사에 버전 관리 항목을 포함했다. 깃은 이 설문조사에서 응답한 개발자들 사이에서 압도적인 선호를 받았으며, 2022년에는 무려 93.9%를 기록했다.

응답한 개발자들이 사용하는 버전 관리 시스템:

이름201520172018 2022
Git69.3%69.2%87.2% 93.9%
Subversion36.9%9.1%16.1% 5.2%
TFVC12.2%7.3%10.9% [ii]
머큐리얼7.9%1.9%3.6% 1.1%
CVS4.2%[ii][ii] [ii]
Perforce3.3%[ii][ii] [ii]
VSS[ii]0.6%[ii] [ii]
IBM 데브옵스 코드 클리어케이스[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%가 깃을 언급하여,[108] 마이크로소프트 Team Foundation Server(12.17%),[109] Subversion(10.60%),[110] 머큐리얼(1.30%),[111] 그리고 Visual SourceSafe(0.48%)를 앞섰다.[112]

확장 도구

[편집]

깃 LFS와 같이 많은 깃 확장 도구가 존재한다. Git LFS는 깃허브 커뮤니티에서 깃 확장으로 시작되었으나 현재는 다른 저장소들에서도 널리 사용된다. 확장 도구들은 보통 서로 다른 사람들에 의해 독립적으로 개발되고 유지보수되지만, 미래의 어느 시점에 널리 사용되는 확장 도구는 깃에 병합될 수도 있다.

다른 오픈 소스 깃 확장 도구는 다음과 같다.

  • git-annex: 깃에 기반한 분산 파일 동기화 시스템
  • git-flow: Vincent Driessen의 브랜칭 모델을 위한 고수준 저장소 작업을 제공하는 깃 확장 세트
  • git-machete: 저장소 정리 및 rebase/merge/pull/push 작업 자동화를 위한 도구

마이크로소프트는 2017년 Perforce에서 이주하면서 윈도우 소스 코드 트리의 크기를 감당하기 위해 Virtual File System for Git(VFS for Git; 이전 명칭 Git Virtual File System 또는 GVFS) 확장을 개발했다. VFS for 깃을 사용하면 복제된 저장소가 플레이스홀더를 사용하고, 파일에 실제로 접근할 때만 내용을 다운로드하도록 할 수 있다.[113]

관례

[편집]

깃은 다양한 방식으로 사용될 수 있지만, 일반적으로 몇 가지 관례가 채택된다.

  • 로컬 저장소를 생성하는 명령어인 git init은 master라는 이름의 브랜치를 생성한다.[64][114] 이는 종종 변경 사항을 머지하기 위한 통합 브랜치로 사용된다.[115] 깃허브[116]와 깃랩[117] 같은 일부 도구는 대신 main이라는 이름의 기본 브랜치를 생성한다. Git 자체도 2026년 말로 예상되는 3.0 릴리스부터 main을 사용하기 시작하기로 했다.[118] 기본 업스트림 원격 저장소 이름이 origin이므로,[119] 기본 원격 브랜치는 origin/master가 된다. 또한 사용자는 브랜치를 추가하거나 삭제할 수 있으며 통합을 위해 어떤 브랜치든 선택할 수 있다.
  • 푸시된 커밋은 일반적으로 덮어쓰지 않고, 이전 커밋을 반전시키는 다른 변경 사항을 커밋함으로써 되돌린다(revert).[120] 이는 기반이 되는 커밋이 원격에 존재하지 않아 공유된 커밋이 무효화되는 것을 방지한다. 만약 커밋에 민감한 정보가 포함되어 있다면 이를 제거해야 하며, 이는 이력을 재작성하는 더 복잡한 절차를 수반한다.
  • git-flow[121] 워크플로와 명명 관례는 기능별 불안정 이력(feature/*), 불안정 공유 이력(develop), 출시 준비 완료 이력(main), 그리고 출시 제품에 대한 긴급 패치(hotfix)를 구분하기 위해 종종 채택된다.
  • 풀 리퀘스트(pull request), 또는 머지 리퀘스트(merge request)는 사용자가 한 브랜치를 다른 브랜치로 머지해달라고 요청하는 것이다.[122][123] 깃 자체가 풀 리퀘스트 기능을 제공하는 것은 아니지만, 이는 깃 클라우드 서비스들의 공통된 기능이다. 풀 리퀘스트의 근본적인 기능은 저장소 관리자가 다른 원격(풀 리퀘스트의 소스가 된 저장소)으로부터 변경 사항을 가져오는 것과 다르지 않다. 그러나 풀 리퀘스트 자체는 이러한 작업을 수행하는 호스팅 서버에 의해 관리되는 티켓이며, Git SCM의 기능은 아니다.

보안

[편집]

깃은 접근 제어 메커니즘을 제공하지 않으며, 접근 제어를 전문으로 하는 다른 도구와 함께 작동하도록 설계되었다.[124]

2014년 12월 17일, 깃 클라이언트의 윈도우 및 macOS 버전에 영향을 미치는 취약점이 발견되었다. 공격자는 깃 저장소 내의 모든 데이터를 저장하는 .git 디렉토리를 대소문자만 다르게(예: .GIT 또는 .Git) 생성하고 그 안의 .git/hooks 하위 디렉토리에 악성 파일을 넣음으로써, 깃이 설치된 대상 컴퓨터에서 임의 코드 실행을 수행할 수 있었다. 윈도우나 Mac 사용자가 이 악성 디렉토리가 포함된 저장소 버전을 pull(다운로드)하고 해당 디렉토리로 전환하면, 대소문자를 구분하지 않는 윈도우 및 Mac 파일 시스템 특성상 .git 디렉토리가 덮어씌워지며 .git/hooks 내의 악성 실행 파일이 실행될 수 있었다. 공격자는 또한 .git/config 설정 파일을 수정하여 악성 깃 에일리어스를 만들거나 기존 에일리어스를 수정하여 실행 시 악성 명령이 수행되게 할 수도 있었다. 이 취약점은 2014년 12월 17일에 출시된 Git 2.2.1 버전에서 패치되었으며 다음 날 발표되었다.[125][126]

2015년 9월 29일에 출시된 Git 2.6.1 버전에는 임의 코드 실행을 가능하게 하는 보안 취약점(CVE-2015-7545)에 대한 패치가 포함되었다.[127][128] 이 취약점은 공격자가 특정 URL을 클론하도록 피해자를 설득할 수 있는 경우 악용될 수 있었는데, 이는 임의의 명령이 URL 자체에 내장되어 있었기 때문이다.[129] 연결이 암호화되지 않은 경우 공격자는 중간자 공격을 통해 사용자를 원하는 URL로 리디렉션하여 이 취약점을 이용할 수 있었다.[129] 재귀적 클론 또한 저장소 관리자가 gitmodules 파일을 통해 임의의 URL을 지정할 수 있었기 때문에 취약했다.[129]

깃은 내부적으로 SHA-1 해시를 사용한다. 리누스 토르발스는 이 해시가 주로 우발적인 손상을 방지하기 위한 것이며, 암호학적으로 안전한 해시가 주는 보안은 단지 부수적인 효과일 뿐이며, 주요 보안은 다른 곳에서의 디지털 서명이라고 답했다.[130][131] 2017년 깃을 대상으로 한 SHAttered 공격 시연 이후, 깃은 이 공격에 내성이 있는 SHA-1 변형을 사용하도록 수정되었다. 2020년 2월부터 해시 함수 전환 계획이 작성되고 있다.[132]

상표

[편집]

"Git"은 2015년 2월 3일부터 미국 등록 번호 US500000085961336으로 소프트웨어 자유 단체가 보유한 등록 단어 상표이다.

같이 보기

[편집]

각주

[편집]
  1. ↑ “Initial revision of "git", the information manager from hell”. GitHub. 2005년 4월 8일. 2015년 11월 16일에 원본 문서에서 보존된 문서. 2015년 12월 20일에 확인함.
  2. ↑ “Commit Graph”. GitHub. 2016년 6월 8일. 2016년 1월 20일에 원본 문서에서 보존된 문서. 2015년 12월 19일에 확인함.
  3. ↑ Junio C Hamano (2026년 9월 28일). “[ANNOUNCE] Git v2.56.0”. 2026년 9월 28일에 확인함.
  4. ↑ “Git website”. 2022년 6월 9일에 원본 문서에서 보존된 문서. 2022년 6월 9일에 확인함.
  5. ↑ “Git Source Code Mirror”. 《GitHub》. 2022년 6월 3일에 원본 문서에서 보존된 문서. 2022년 6월 9일에 확인함.
  6. ↑ “Git's LGPL license at github.com”. 《GitHub》. 2011년 5월 20일. 2016년 4월 11일에 원본 문서에서 보존된 문서. 2014년 10월 12일에 확인함.
  7. ↑ “Git's GPL license at github.com”. 《GitHub》. 2010년 1월 18일. 2016년 4월 11일에 원본 문서에서 보존된 문서. 2014년 10월 12일에 확인함.
  8. ↑ 《Tech Talk: Linus Torvalds on git》. 2007년 5월 14일. 00:01:30에 발생. 2015년 12월 20일에 원본 문서에서 보존된 문서. 2014년 7월 20일에 확인함 – YouTube 경유.
  9. ↑ Chacon & Straub 2014, 29–31쪽.
  10. 1 2 Torvalds, Linus (2005년 4월 7일). “Re: Kernel SCM saga...” (메일링 리스트). 《linux-kernel》. 2019년 7월 1일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함. "So I'm writing some scripts to try to track things a whole lot faster."
  11. 1 2 Torvalds, Linus (2007년 6월 10일). “Re: fatal: serious inflate inconsistency” (메일링 리스트). 《git》. 2022년 12월 28일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  12. 1 2 3 4 Linus Torvalds (2007년 5월 3일). 《Google tech talk: Linus Torvalds on git》. 02:30에 발생. 2007년 5월 28일에 원본 문서에서 보존된 문서. 2007년 5월 16일에 확인함.
  13. ↑ Chacon, Scott (2014년 12월 24일). 《Pro Git》 2판. New York, NY: Apress. 29–30쪽. ISBN 978-1-4842-0077-3. 2015년 12월 25일에 원본 문서에서 보존된 문서.
  14. 1 2 〈A Short History of Git〉 2판. 《Pro Git》. Apress. 2014. 2015년 12월 25일에 원본 문서에서 보존된 문서. 2015년 12월 26일에 확인함.
  15. ↑ Shirey, Russell G. (2015년 3월 1일). “Git as an Encrypted Distributed Version Control System” (PDF). 《Defense Technical Information Center》. 38쪽. 2025년 7월 13일에 확인함.
  16. ↑ Knüpfer, Andreas; Callow, Timothy J. (2025). “Data Version Management and Machine-Actionable Reproducibility for HPC based on git and DataLad”. arXiv:2505.06558 [cs.DC].
  17. 1 2 “Stack Overflow Developer Survey 2022” (영어). 《Stack Overflow》. 2022년 6월 27일에 원본 문서에서 보존된 문서. 2022년 8월 4일에 확인함.
  18. ↑ Krill, Paul (2016년 9월 28일). “Enterprise repo wars: GitHub vs. GitLab vs. Bitbucket”. 《InfoWorld》. 2020년 2월 2일에 원본 문서에서 보존된 문서. 2020년 2월 2일에 확인함.
  19. 1 2 “github.com Competitive Analysis, Marketing Mix and Traffic”. 《Alexa》. 2013년 3월 31일에 원본 문서에서 보존된 문서. 2020년 2월 2일에 확인함.
  20. 1 2 “sourceforge.net Competitive Analysis, Marketing Mix and Traffic”. 《Alexa》. 2020년 10월 20일에 원본 문서에서 보존된 문서. 2020년 2월 2일에 확인함.
  21. 1 2 “bitbucket.org Competitive Analysis, Marketing Mix and Traffic”. 《Alexa》. 2017년 6월 23일에 원본 문서에서 보존된 문서. 2020년 2월 2일에 확인함.
  22. 1 2 “gitlab.com Competitive Analysis, Marketing Mix and Traffic”. 《Alexa》. 2017년 11월 30일에 원본 문서에서 보존된 문서. 2020년 2월 2일에 확인함.
  23. ↑ Brown, Zack (2018년 7월 27일). “A Git Origin Story”. 《Linux Journal》 (Linux Journal). 2020년 4월 13일에 원본 문서에서 보존된 문서. 2020년 5월 28일에 확인함.
  24. ↑ “BitKeeper and Linux: The end of the road?” (미국 영어). 《Linux.com》. 2005년 4월 11일. 2023년 5월 18일에 확인함.
  25. ↑ McAllister, Neil (2005년 5월 2일). “Linus Torvalds' BitKeeper blunder”. 《InfoWorld》. 2015년 8월 26일에 원본 문서에서 보존된 문서. 2015년 9월 8일에 확인함.
  26. 1 2 Torvalds, Linus (2007년 2월 27일). “Re: Trivia: When did git self-host?” (메일링 리스트). 《git》. 2023년 4월 8일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  27. ↑ Torvalds, Linus (2005년 4월 6일). “Kernel SCM saga..” (메일링 리스트). 《linux-kernel》. 2023년 6월 8일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  28. ↑ Torvalds, Linus (2005년 4월 17일). “First ever real kernel git merge!” (메일링 리스트). 《git》. 2021년 8월 15일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  29. ↑ Mackall, Matt (2005년 4월 29일). “Mercurial 0.4b vs git patchbomb benchmark” (메일링 리스트). 《git》. 2021년 8월 15일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  30. ↑ Torvalds, Linus (2005년 6월 17일). “Linux 2.6.12” (메일링 리스트). 《git-commits-head》.
  31. ↑ Torvalds, Linus (2005년 7월 27일). “Meet the new maintainer..” (메일링 리스트). 《git》. 2021년 8월 15일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  32. ↑ Hamano, Junio C. (2005년 12월 21일). “Announce: Git 1.0.0” (메일링 리스트). 《git》. 2021년 8월 16일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  33. ↑ “GitFaq: Why the 'Git' name?”. Git.or.cz. 2012년 7월 23일에 원본 문서에서 보존된 문서. 2012년 7월 14일에 확인함.
  34. ↑ “After controversy, Torvalds begins work on 'git'”. 《PC World》. 2012년 7월 14일. 2011년 2월 1일에 원본 문서에서 보존된 문서. 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.'
  35. ↑ “git(1) Manual Page”. 2012년 6월 21일에 원본 문서에서 보존된 문서. 2012년 7월 21일에 확인함.
  36. ↑ “Initial revision of 'git', the information manager from hell · git/git@e83c516”. 《GitHub》. 2017년 10월 8일에 원본 문서에서 보존된 문서. 2016년 1월 21일에 확인함.
  37. ↑ “git/usage.c at master · git/git” (영어). 《GitHub》. 2025년 2월 26일에 원본 문서에서 보존된 문서. 2025년 7월 11일에 확인함.
  38. ↑ Torvalds, Linus (2005년 4월 7일). “Initial revision of "git", the information manager from hell · git/git@e83c516” (영어). 《GitHub》. 2015년 11월 16일에 원본 문서에서 보존된 문서. 2025년 7월 11일에 확인함.
  39. ↑ “Git – Distributed Workflows”. 《Git》. 2014년 10월 22일에 원본 문서에서 보존된 문서. 2020년 6월 15일에 확인함.
  40. ↑ Gunjal, Siddhesh (2019년 7월 19일). “What is Version Control Tool? Explore Git and GitHub” (영어). 《Medium》. 2025년 4월 17일에 원본 문서에서 보존된 문서. 2020년 10월 25일에 확인함.
  41. ↑ Torvalds, Linus (2006년 10월 19일). “Re: VCS comparison table” (메일링 리스트). 《git》. 2017년 6월 18일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  42. ↑ Dreier, Roland (2006년 11월 13일). “Oh what a relief it is”. 2009년 1월 16일에 원본 문서에서 보존된 문서., "git log"가 "svn log"보다 100배 더 빠른데, 후자는 원격 서버에 접속해야 하기 때문이라고 관찰함.
  43. ↑ “Trust”. 《Git Concepts》. Git User's Manual. 2006년 10월 18일. 2017년 2월 22일에 원본 문서에서 보존된 문서.
  44. ↑ Torvalds, Linus. “Re: VCS comparison table” (메일링 리스트). 《git》. 2016년 4월 11일에 원본 문서에서 보존된 문서. 2009년 4월 10일에 확인함., 깃의 스크립트 지향 설계를 설명함
  45. ↑ iabervon (2005년 12월 22일). “Git rocks!”. 2016년 9월 14일에 원본 문서에서 보존된 문서., 깃의 스크립트 가능성을 칭찬함.
  46. ↑ “Git – Git SCM Wiki”. 《git.wiki.kernel.org》. 2010년 2월 6일에 원본 문서에서 보존된 문서. 2020년 10월 25일에 확인함.
  47. ↑ Chacon & Straub 2014.
  48. ↑ “Git User's Manual”. 2020년 3월 10일. 2020년 5월 10일에 원본 문서에서 보존된 문서.
  49. ↑ Chacon & Straub 2014, 499쪽.
  50. ↑ Chacon & Straub 2014, 33–34쪽.
  51. 1 2 “Git – Packfiles”. 《Git》. 2025년 7월 26일에 원본 문서에서 보존된 문서. 2025년 8월 25일에 확인함.
  52. ↑ Chacon & Straub 2014, 568쪽.
  53. ↑ Torvalds, Linus (2005년 4월 10일). “Re: more git updates..” (메일링 리스트). 《linux-kernel》. 2017년 6월 18일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  54. ↑ Haible, Bruno (2007년 2월 11일). “how to speed up 'git log'?” (메일링 리스트). 《git》. 2017년 6월 18일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  55. ↑ Torvalds, Linus (2006년 3월 1일). “Re: impure renames / history tracking” (메일링 리스트). 《git》. 2017년 5월 3일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  56. ↑ Hamano, Junio C. (2006년 3월 24일). “Re: Errors GITtifying GCC and Binutils” (메일링 리스트). 《git》. 2017년 6월 18일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  57. ↑ Hamano, Junio C. (2006년 3월 23일). “Re: Errors GITtifying GCC and Binutils” (메일링 리스트). 《git》. 2017년 6월 18일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  58. ↑ Torvalds, Linus (2006년 11월 28일). “Re: git and bzr” (메일링 리스트). 《git》. 2017년 6월 18일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함., 소스 파일 간에 이동된 코드를 보여주기 위해 git-blame을 사용하는 것에 대해.
  59. ↑ Torvalds, Linus (2007년 7월 18일). “git-merge(1)”. 2016년 7월 16일에 원본 문서에서 보존된 문서.
  60. ↑ Torvalds, Linus (2007년 7월 18일). “CrissCrossMerge”. 2006년 1월 13일에 원본 문서에서 보존된 문서.
  61. ↑ Torvalds, Linus (2005년 4월 10일). “Re: more git updates...” (메일링 리스트). 《linux-kernel》. 2017년 6월 18일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  62. ↑ Torvalds, Linus (2006년 3월 23일). “Re: Errors GITtifying GCC and Binutils” (메일링 리스트). 《git》. 2021년 3월 22일에 원본 문서에서 보존된 문서. 2017년 2월 3일에 확인함.
  63. ↑ “Git – Git Objects”. 《Git》. 2025년 7월 29일에 원본 문서에서 보존된 문서. 2025년 8월 25일에 확인함.
  64. 1 2 Chacon & Straub 2014, 81–83쪽.
  65. ↑ Chacon & Straub 2014, 485–488쪽.
  66. ↑ Chacon & Straub 2014, 488–490쪽.
  67. ↑ Chacon & Straub 2014, 495–496쪽.
  68. ↑ Chacon & Straub 2014, 497–501쪽.
  69. ↑ “Git – Git References”. 《Git》. 2025년 7월 26일에 원본 문서에서 보존된 문서. 2025년 8월 25일에 확인함.
  70. ↑ “Git Cheat Sheet” (PDF). 《education.github.com》. 2024년 6월 19일에 원본 문서 (PDF)에서 보존된 문서. 2024년 6월 10일에 확인함.
  71. ↑ “Git Tutorial” (PDF). 《web.stanford.edu》. 2024년 6월 10일에 원본 문서 (PDF)에서 보존된 문서. 2024년 6월 10일에 확인함.
  72. ↑ “Git Quick Intro” (PDF). 《data-skills.github.io》. 2024년 6월 23일에 원본 문서 (PDF)에서 보존된 문서. 2024년 6월 10일에 확인함.
  73. ↑ Ba Tran, Andrew. “Best practices for uploading to GitHub” (PDF). 《journalismcourses.org》. 2024년 9월 10일에 원본 문서 (PDF)에서 보존된 문서. 2024년 6월 10일에 확인함.
  74. ↑ “Project Configuration File Format”. 《Gerrit Code Review》. 2020년 12월 3일에 원본 문서에서 보존된 문서. 2020년 2월 2일에 확인함.
  75. ↑ “downloads”. 2012년 5월 8일에 원본 문서에서 보존된 문서. 2012년 5월 14일에 확인함.
  76. ↑ “git package versions – Repology”. 2022년 1월 19일에 원본 문서에서 보존된 문서. 2021년 11월 30일에 확인함.
  77. ↑ “msysGit”. 《GitHub》. 2016년 10월 10일에 원본 문서에서 보존된 문서. 2016년 9월 20일에 확인함.
  78. ↑ “Git – Downloading Package”. 《Git》. 2025년 7월 29일에 원본 문서에서 보존된 문서. 2025년 8월 25일에 확인함. (소스 코드 보관됨 26 7월 2025 - 웨이백 머신)
  79. ↑ “JGit”. 2012년 8월 31일에 원본 문서에서 보존된 문서. 2012년 8월 24일에 확인함.
  80. ↑ “Git – go-git”. 《Git》. 2025년 4월 22일에 원본 문서에서 보존된 문서. 2019년 4월 19일에 확인함.
  81. ↑ “SQL interface to Git repositories, written in Go.”, 《github.com》, 2025년 6월 22일에 원본 문서에서 보존된 문서, 2019년 4월 19일에 확인함
  82. ↑ “Keybase launches encrypted git”. 《keybase.io》. 2018년 5월 16일에 원본 문서에서 보존된 문서. 2019년 4월 19일에 확인함.
  83. ↑ “Dulwich GitHub Repository README.md”. 《GitHub》. 2024년 4월 29일에 원본 문서에서 보존된 문서. 2024년 4월 29일에 확인함.
  84. ↑ “libgit2”. 《GitHub》. 2016년 4월 11일에 원본 문서에서 보존된 문서. 2012년 8월 24일에 확인함.
  85. ↑ “rugged”. 《GitHub》. 2013년 7월 24일에 원본 문서에서 보존된 문서. 2012년 8월 24일에 확인함.
  86. ↑ “pygit2”. 《GitHub》. 2015년 8월 5일에 원본 문서에서 보존된 문서. 2012년 8월 24일에 확인함.
  87. ↑ “hlibgit2”. 2013년 5월 25일에 원본 문서에서 보존된 문서. 2013년 4월 30일에 확인함.
  88. ↑ “js-git: a JavaScript implementation of Git”. 《GitHub》. 2013년 8월 7일에 원본 문서에서 보존된 문서. 2013년 8월 13일에 확인함.
  89. ↑ “Game of Trees”. 《gameoftrees.org》. 2025년 7월 18일에 원본 문서에서 보존된 문서. 2024년 3월 10일에 확인함.
  90. ↑ “git webls”. 《orib.dev》. 2025년 2월 10일에 원본 문서에서 보존된 문서. 2025년 9월 21일에 확인함.
  91. ↑ “selfhosting git9”. 《orib.dev》. 2025년 2월 10일에 원본 문서에서 보존된 문서. 2025년 9월 21일에 확인함.
  92. ↑ “gitoxide: a Rust implementation of Git”. 《GitHub》. 2025년 12월 18일에 확인함.
  93. ↑ Chacon & Straub 2014, 138–139쪽.
  94. ↑ “Git – Git Daemon”. 《Git》. 2025년 5월 30일에 원본 문서에서 보존된 문서. 2019년 7월 10일에 확인함.
  95. ↑ 4.4 Git on the Server – Setting Up the Server 보관됨 22 10월 2014 - 웨이백 머신, Pro Git.
  96. ↑ “1.4 Getting Started – Installing Git”. Git. 2013년 11월 2일에 원본 문서에서 보존된 문서. 2013년 11월 1일에 확인함.
  97. ↑ Chacon, Scott; Straub, Ben (2014). 〈Git on the Server – Setting Up the Server〉 2판. 《Pro Git》. Apress. ISBN 978-1484200773. 2025년 7월 30일에 원본 문서에서 보존된 문서. 2025년 8월 25일에 확인함.
  98. ↑ Diffusion User Guide: Repository Hosting 보관됨 20 9월 2020 - 웨이백 머신.
  99. ↑ “Highlights from Git 2.26” (미국 영어). 《The GitHub Blog》. 2020년 3월 22일. 2021년 3월 22일에 원본 문서에서 보존된 문서. 2020년 11월 25일에 확인함. 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.
  100. ↑ “Git - git-gui Documentation” (영어). 《Git》. 2025년 7월 26일에 원본 문서에서 보존된 문서. 2024년 7월 1일에 확인함.
  101. ↑ “Git - GUI Clients” (영어). 《Git》. 2025년 7월 28일에 원본 문서에서 보존된 문서. 2024년 7월 1일에 확인함.
  102. ↑ “Eclipse Community Survey 2014 results | Ian Skerrett”. Ianskerrett.wordpress.com. 2014년 6월 23일. 2014년 6월 25일에 원본 문서에서 보존된 문서. 2014년 6월 23일에 확인함.
  103. ↑ “Results of Eclipse Community Survey 2012”. eclipse.org. 2016년 4월 11일에 원본 문서에서 보존된 문서.
  104. ↑ “Compare Repositories – Open Hub”. 2014년 9월 7일에 원본 문서에서 보존된 문서.
  105. ↑ “Stack Overflow Developer Survey 2015”. Stack Overflow. 2019년 5월 4일에 원본 문서에서 보존된 문서. 2019년 5월 29일에 확인함.
  106. ↑ “Stack Overflow Developer Survey 2017”. Stack Overflow. 2019년 5월 29일에 원본 문서에서 보존된 문서. 2019년 5월 29일에 확인함.
  107. ↑ “Stack Overflow Developer Survey 2018”. Stack Overflow. 2019년 5월 30일에 원본 문서에서 보존된 문서. 2019년 5월 29일에 확인함.
  108. ↑ “Git (software) Jobs, Average Salary for Git Distributed Version Control System Skills”. Itjobswatch.co.uk. 2016년 10월 8일에 원본 문서에서 보존된 문서. 2016년 9월 30일에 확인함.
  109. ↑ “Team Foundation Server Jobs, Average Salary for Microsoft Team Foundation Server (TFS) Skills”. Itjobswatch.co.uk. 2016년 10월 29일에 원본 문서에서 보존된 문서. 2016년 9월 30일에 확인함.
  110. ↑ “Subversion Jobs, Average Salary for Apache Subversion (SVN) Skills”. Itjobswatch.co.uk. 2016년 10월 25일에 원본 문서에서 보존된 문서. 2016년 9월 30일에 확인함.
  111. ↑ “Mercurial Jobs, Average Salary for Mercurial Skills”. Itjobswatch.co.uk. 2016년 9월 23일에 원본 문서에서 보존된 문서. 2016년 9월 30일에 확인함.
  112. ↑ “VSS/SourceSafe Jobs, Average Salary for Microsoft Visual SourceSafe (VSS) Skills”. Itjobswatch.co.uk. 2016년 10월 29일에 원본 문서에서 보존된 문서. 2016년 9월 30일에 확인함.
  113. ↑ “Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day”. 《Ars Technica》. 2017년 5월 24일. 2017년 5월 24일에 원본 문서에서 보존된 문서. 2017년 5월 24일에 확인함.
  114. ↑ “git-init”. 《Git》. 2022년 3월 15일에 원본 문서에서 보존된 문서.
  115. ↑ “Git – Branches in a Nutshell”. 《Git》. 2020년 12월 20일에 원본 문서에서 보존된 문서. 2020년 6월 15일에 확인함. 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.
  116. ↑ 《github/renaming》, GitHub, 2020년 12월 4일, 2025년 7월 26일에 원본 문서에서 보존된 문서, 2020년 12월 4일에 확인함
  117. ↑ 《Default branch name for new repositories now main》, GitLab, 2021년 6월 22일, 2025년 5월 19일에 원본 문서에서 보존된 문서, 2021년 6월 22일에 확인함
  118. ↑ “Git 2.52 Released With More Preparations Toward Git 3.0” (영어). 《www.phoronix.com》. 2025년 12월 19일에 확인함.
  119. ↑ Chacon & Straub 2014, 103–109쪽.
  120. ↑ “Git Revert | Atlassian Git Tutorial” (영어). 《Atlassian》. 2025년 6월 19일에 원본 문서에서 보존된 문서. 2025년 8월 25일에 확인함. 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.
  121. ↑ “Gitflow Workflow | Atlassian Git Tutorial” (영어). 《Atlassian》. 2020년 6월 15일에 확인함.
  122. ↑ Chacon & Straub 2014, 170–174쪽.
  123. ↑ “Forking Workflow | Atlassian Git Tutorial” (영어). 《Atlassian》. 2020년 6월 24일에 원본 문서에서 보존된 문서. 2020년 6월 15일에 확인함.
  124. ↑ “Git repository access control”. 2016년 9월 14일에 원본 문서에서 보존된 문서. 2016년 9월 6일에 확인함.
  125. ↑ Pettersen, Tim (2014년 12월 20일). “Securing your Git server against CVE-2014-9390”. 2014년 12월 24일에 원본 문서에서 보존된 문서. 2014년 12월 22일에 확인함.
  126. ↑ Hamano, J. C. (2014년 12월 18일). “[Announce] Git v2.2.1 (and updates to older maintenance tracks)”. 뉴스그룹: gmane.linux.kernel. 2014년 12월 19일에 원본 문서에서 보존된 문서. 2014년 12월 22일에 확인함.
  127. ↑ “CVE-2015-7545”. 2015년 12월 15일. 2015년 12월 26일에 원본 문서에서 보존된 문서. 2015년 12월 26일에 확인함.
  128. ↑ “Git 2.6.1”. 《GitHub》. 2015년 9월 29일. 2016년 4월 11일에 원본 문서에서 보존된 문서. 2015년 12월 26일에 확인함.
  129. 1 2 3 Blake Burkhart 외 (2015년 10월 5일). “Re: CVE Request: git”. 2015년 12월 27일에 원본 문서에서 보존된 문서. 2015년 12월 26일에 확인함.
  130. ↑ “hash – How safe are signed git tags? Only as safe as SHA-1 or somehow safer?”. Information Security Stack Exchange. 2014년 9월 22일. 2016년 6월 24일에 원본 문서에서 보존된 문서.
  131. ↑ “Why does Git use a cryptographic hash function?”. Stack Overflow. 2015년 3월 1일. 2016년 7월 1일에 원본 문서에서 보존된 문서.
  132. ↑ “Git – hash-function-transition Documentation”. 《Git》.
내용주
  1. ↑ 2005-04-11부터 GPL-2.0-only. 일부 파트는 LGPLv2.1과 같은 호환 라이선스 하에 있음.[6]
  2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 이 설문조사에서는 옵션으로 나열되지 않음

외부 링크

[편집]
  • 위키미디어 공용에 깃 관련 미디어 분류가 있습니다.
  • 깃 위키데이터에서 편집하기 - 공식 웹사이트
  • (영어) Git - 오픈 허브
원본 주소 "https://ko.wikipedia.org/w/index.php?title=깃_(소프트웨어)&oldid=42489226"