| <colbgcolor=#ffffff,#1f2023><colcolor=#413000,#ddd> Git | |
| | |
| 종류 | 버전 관리 시스템(VCS) |
| 라이선스 | GPLv2 |
| 개발 | 리누스 토르발스 외 |
| 언어 | C(49.9%), Shell(37.8%) 등 |
| 최초 공개일 | 2005년 4월 7일 |
| 버전 | v2.41.0 |
| | |
[clearfix]
1. 개요
리누스 토르발스가 개발한 분산형 버전 관리 시스템(VCS)이다.2. 상세
오픈소스계의 영원한 아이돌 리누스 토르발스는 리눅스 커널을 관리하는 기존 툴이 엉망인 것에 너무 빡친 바람에 Git이라는 소스관리 툴을 만든다. 리누스는 하도 빡친 나머지, 단 2주만에 완성하는 기염을 토했다.
－오픈소스의 승리 중에서.
－오픈소스의 승리 중에서.
Git은 매우 빠른 속도와 분산형 저장소 지원이 특징이다. 방대한 Linux 커널 소스 코드를 생각해 보면, 속도 문제는 매우 중요하다. 오픈 소스 개발의 특성상 여럿이 달려들어 자기 맘에 드는 걸 하기도 하며, 또한 뭘 하나 잘못 붙였다 이상한 걸 건드려 망하기 쉬운데, Git는 이런 환경의 특성에 맞게끔 제작되었다.
Git 자체는 오픈 소스이며 저장소는 git.kernel.org이다[1]. git clone으로 프로젝트를 클론한 후 빌드해볼 수 있으며, 전체 저장소를 클론하고 싶지 않다면 kernel.org에서 원하는 버전의 tar파일을 찾아서 다운로드 할 수 있다. GitHub에 git/git이라는 미러 저장소도 있으며, 정확히 동일한 내용을 가지고 있다.[2]
2.1. 개발 비화
Git의 개발 비화를 다룬 만화리누스 토르발스는 초기에 리눅스 커널 소스 코드를 관리할 때 SVN(Subversion)이나 CVS(Concurrent Versions System) 같은 기존의 버전 관리 시스템을 아예 사용하지 않았다. 사용하지 않은 이유는 기능이 마음에 들지 않았다는게 정설이며, 수많은 사람들이 보내오는 메일링 리스트로 다른 개발자의 기여 내용을 관리하고 있었다. 그러다가 그도 결국 버틸 수 없었는지 버전 관리 시스템을 사용하기로 결정했는데, 그가 선택한 것은 BitKeeper[3]라는 프로그램이었다. BitKeeper는 상용 S/W였지만 분산 처리 기능과 비교적 빠른 성능 덕분에 사용했다고 한다. 토르발스의 이런 선택은 자유 소프트웨어 진영으로부터 지탄을 받았으나 자유 소프트웨어 진영에서도 마땅한 대안을 제시하지는 못했다.
그러다가 BitKeeper 쪽에서 리버스 엔지니어링을 문제로 일부 리눅스 개발자들을 제한하는 일이 발생했다. 그런 일이 발생하자 토르발스는 BitKeeper를 계속 쓸지 아니면 다른 버전 관리 시스템을 사용할지 결정해야 했는데, 토르발스의 선택은 제3의 길이었다. 그냥 자신이 직접 버전 관리 시스템을 만들기로 결정했고 그렇게 뚝딱뚝딱 직접 만든 게 바로 Git이었다. 단 2주만에 완성했다고 한다. 그리고 리눅스 커널 소스를 Git을 이용해서 관리하기 시작했다. 이 때문에 팽당한 BitKeeper는 유료 정책도 포기하고 무료로 풀었으며 심지어 아파치 라이선스로 소스까지 공개한 상태지만 대세를 거스를 순 없었다. 현재는 Git이 SVN, Mercurial, CVS 등 여타 버전 관리 시스템들을 큰 격차로 누르고 압도적인 점유율을 차지하고 있다. #
리누스가 리눅스 저장소에 적용하며 등장했다는 상징성과 유명세 덕에 단번에 큰 관심을 끌었다. 그 이전까지 많이 쓰이던 SVN이나 추격자였던 Mercurial을 단번에 제치고 많은 사용자를 확보했으며, 리누스의 이름값에 모여든 활발한 참여자들의 기여를 통해 지속적으로 기능이 추가 보완되면서 더욱 인기를 끄는 상승작용이 반복되어 부동의 점유율을 자랑하게 되었다. 2010년 이후로 토르발스는 더 이상 메인 컨트리뷰터로 활동하지 않고 리포지토리를 다른 사람에게 넘긴 상태. 현재 gitster와 peff 등이 메인 컨트리뷰터로 활동하고 있다.
오픈 소스가 기존에 치열하게 경쟁하던 상용 소프트웨어 업체들을 무시하고 시장경제를 망가뜨리는 공산주의라고 까던 마이크로소프트는 결국 그 자신들도 Git을 잘 써먹다 못해 Visual Studio 기본 버전 관리시스템으로 Git을 박아버린데다 아예 대표적인 저장소인 GitHub를 인수해버렸고, 구글, 트위터, 모질라 재단 등에서도 Git을 잘 써먹고 있다. 국내에서 유명한 파일 시스템 기반 PHP 위키엔진인 모니위키도 Git으로 관리되고 있다. 윈도우의 경우 2020년 기준으로 90%까지 Git 처리가 완료되었는데, 하루 8500건의 커밋과 더불어 1760번의 빌드를 거친다고 한다.
3. 구조
| |
| Git 구동 원리 |
작업이 끝나면 Git 원격 저장소로 다시 발행하는데, 여기에서도 메인 저장소와 합치기 전 메인 저장소와 격리시키고 따로 개발 할 수 있는 가지라는걸 만들어 가지의 개발이 완료될 시 메인 저장소와 합치고 가지는 삭제시키는 가지치기를 할 수 있으며, 또한 개발 중간중간 꼬리표를 매겨 개발을 더 수월하게 할 수 있다.
4. 장단점
4.1. 장점
- 서로의 코드를 검증하는 피어리뷰에 용이하다.
- 오프라인 작업이 가능하다. TFS 등의 기존 중앙집중형 형상관리 툴은 오프라인 작업을 아예 지원하지 않거나, 매우 제한적으로만 지원하였다. 본인이 특정 파일을 체크아웃했다는 사실이 실시간으로 서버에 드러나야 하기 때문이다. 온라인 상태에서 체크아웃한 파일은 오프라인 상태에서도 계속 작업할 수 있는 경우도 있으나, 이 경우에는 추가적인 형상관리가 안된다. git는 저장소를 일단 로컬에 복제하고, 로컬 저장소에 있는 히스토리도 그대로 유지되므로, 서버에서 새 자료를 받아올 수 없을 뿐이지 이외에는 오프라인 상태에서도 대부분의 형상관리 기능을 이용할 수 있다. 일종의 로컬 서버로 작용하는 셈.
- 속도가 빠르다. 각각의 개발자들이 모두 분산처리 서버의 주인이 되는 셈이므로 서버가 직접 해야 될 일들이 많이 줄어든다.
- 일시적인 서버 장애가 있어도 개발을 계속할 수 있다. 로컬 저장소를 이용하면 되기 때문.
- 서버와 클라이언트 뿐인 기존 형상관리에 비해 분산처리 구조를 유연하게 세울 수 있다. 중간 서버를 둔다든지, 부서별로 따로 서버를 둔다든지 하는 구성이 자유롭게 가능.
- 가지치기(branch)가 비교적 가볍다. 가지치기 자체를 git의 장점으로 꼽기도 하지만 이는 현존하는 대부분의 형상관리 도구가 지원하는 기능이다. 실질적인 차이는 그 구현 방법에 있다고 봐야 한다. git는 브랜칭이 매우 쉽고 가벼워 원하는 만큼 별 제약 없이 생성하고 삭제할 수가 있다. git만 사용해오던 사람은 당연하게 느껴질 것이고 이게 왜 장점인지조차 모를 수 있겠지만, 기존 형상관리 도구를 사용하던 사람들은 브랜칭 하나 하려고 수 시간의 미팅을 해야 하던 때도 있었다.
- 병합(merge)에서 문제가 덜 발생한다. 서버의 자료를 가져와(fetch) 로컬에서 병합하고 이를 다시 올리는 형태이기 때문. 물론 아예 문제가 발생하지 않을 수는 없으나, 이러한 구조 덕분에 예기치 못하게 발생하는 병합 문제 발생 빈도가 낮아진다.
- 스테이징을 지원한다. 단순히 커밋되지 않은 로컬 변동사항을 얘기하는 것이 아니고, 아예 커밋하기 전에 사용해야 하는 스테이징 단계가 따로 있다. 물론 이를 사용하지 않고 다른 형상관리 도구처럼 바로 커밋하는 식으로 사용할 수도 있다.
- 직접 호스팅을 할 경우 상업용 용도로도 무료로 이용 가능한 방법이 존재한다.
- 수많은 개발자용 툴이 Git을 자체 지원하거나, Git용 플러그인이 있다. 또한 관련 툴킷 범위도 넓어, 초보자를 위한 GUI부터 전문자용 Diff툴까지 Git사용에 도움이 되는 툴이 많다. 또한 libgit2 등을 이용하면 원하는 언어로 Git을 활용하는 프로그램을 직접 만들 수도 있다.
4.2. 단점
- 기존 형상관리 도구에 비해 덜 직관적이고 배우기 어렵다. 특히 중앙 집중형 형상관리 도구에 익숙한 사람일수록 귀찮고 어려워지는데, 용어도 컨셉트도 처리과정도 전혀 다르기 때문. 로컬 머신을 작업공간, 서버를 저장공간으로 생각하면 더 이상 복잡한 개념이 필요 없이 체크아웃 후 파일을 수정하고 다시 커밋하기만 하면 되는 중앙집중형 도구에 비해 git는 설계적으로 작업 디렉토리 - 스테이징 공간 - 로컬 저장소 - 원격 저장소 라는 다층구조를 가지고 있으며, 각각의 맡은 역할과 다른 계층과의 상호작용 방식이 단순 반복이 아니라 훨씬 복잡하게 연결된다. 게다가 이들 각각이 모두 실제 파일이 있는 공간을 의미하는 것이 아니라 작업 내용이 관리되는 개념적인 가상 공간과 실제 물리적 저장소가 섞여 있어 혼동을 유발한다.
커밋, 푸시, 풀, 머지, 페치 등 영어 단어상으로는 비슷비슷하지만 구체적인 역할과 의미에 차이가 있는 수많은 용어들이 존재하며 기존의 지식이 이 새로운 컨셉트를 이용하는 데에 크게 방해가 된다. 또한 처음 배우는 경우 어디까지가 서버에 영향을 미치는 행위이고 어디까지가 로컬에서 안전하게 할 수 있는 일인지 명확하게 이해하기가 어려워 명령어 하나하나에 벌벌 떨게 된다.[5] 서버에 있는 자료와 로컬의 자료를 비교하여 커밋 후에 무슨 변화가 일어나는지 미리 명확하게 알 수 있는 기존 형상관리에 비하면 확실히 덜 직관적이다. 바로 이 문제 때문에 기존 형상관리 도구를 계속 사용하는 경우도 많다.
이 때문에 git을 사용하는 유형은 '확실하게 파악한 기능의 커맨드 조합을 안전하게 계속 반복하며 작업하는' 콘솔 명령어 파와, GUI 프로그램에서 규격화하여 제공하는 기능을 맡기고 사용하는 서드파티 프로그램 파로 크게 나뉜다. 둘 모두 결국에는 자신이 충분히 믿을 수 있을 정도로 안전하게 동작하는 범위를 파악한 후, 그 기능을 반복적으로 사용하는 경우가 많다. - 작업 계층 구조(작업 내용 - 스테이징 공간 - 로컬 저장소 - 원격 저장소 등)에 대한 '기능' 은 매우 명확하게 만들어져 있고 그 동작도 일정하지만, 정작 이를 해석해서 추상화하는 사람들의 해석과 설명이 제각각인 경우가 많다. 단적으로 구글에 'Git Workflow'만 검색해 봐도, '알기 쉬운 도표' 들이 수없이 검색되지만 완전히 똑같이 생긴 것이 없다시피 할 정도다. 앞에 언급한 작업 계층 구조의 명칭-역할의 조합에 미묘한 차이가 있는 것은 물론이고, 아예 특정 단계가 없어 단계의 숫자가 다르고, 도표에서 화살표로 표시된 각 명령어가 어느 단계에서 어느 단계로 오가는 작업인지조차 잘 뜯어보면 조금씩 다 다르다. 이는 git의 명령어가 명시적으로 특정 단계와 특정 단계가 연결된다고 딱 잘라 말할 수 없고, 그것을 단순히 화살표 하나로 표시할 수 없는 미묘한(그러나 나름 의미가 있는) 동작을 하기 때문이다. 이 때문에 'git에 익숙해진 사용자' 는 스스로 각 명령어에 대해 체감적으로 이해하고 있고 손에 익어 사용하고 있다고 느끼지만, 정작 그것을 표현하려고 보면 각 사용자끼리 표현방식이 일치하지 않는 복잡미묘한 개개인 직관의 문화가 정착되어 있다.
- 한 번에 여러 브랜치나 여러 태그에 걸쳐서 커밋을 할 수 없다. 내가 만든 사소한 변동사항이 다른 브랜치에 자동적으로 알려지지 않고, 나중에 취합하는 시점이 돼서야 반영된다. 때에 따라선 이후 다른 브랜치와 병합하려 할 때 충돌의 원인이 될 수도 있다.
- 하나의 저장소가 하나의 프로젝트 전체를 의미하는 것으로 강제되어 있어 일부만 브랜칭을 한다든지 클론을 한다든지 하는 일을 할 수 없다. 정책적인 부분이라 관점에 따라 장점이 될 수도 있겠지만, 해당 기능이 꼭 필요한 사람이라면 단점이 될 수 있다.
- push를 했다 해서 커밋 히스토리가 영원히 안전하게 저장된다고 장담할 수 없다. 중앙 집중형 형상관리에서는 일단 체크인을 하고 나면 서버에 문제가 생기지 않는 한에는 항상 안전하고 언제든 과거 기록을 볼 수 있으나, git에서는 push를 한 내용이라 하더라도 해당 브랜치가 다른 브랜치에 병합되기 전에 삭제돼버리면 나중에 해당 내용에 접근할 수 없다.
- 커밋 ID가 긴 16진수 숫자(SHA-1 해시값)라 기억하기가 어렵고 항상 복사-붙여넣기를 해야 한다. 단순한 10진수 숫자로만 구성되어 있는 TFS 등에 비해 복잡한 것은 사실이다.
- 서버에 저장소를 두고 로컬 머신에서는 작업중인 프로젝트만을 두는 것이 설계개념상 불가능하다. 원격 저장소와 로컬 저장소를 모두 요구하기 때문에 저장소 전체를 받아서 작업해야 된다는 부분도 원하지 않는 경우 단점이다. 작업 패턴이 git에 맞추어져 있다면 로컬 저장소 작업 공간 자체를 '원래 없었던 용량' 으로 생각하고 branch 등으로 늘어나는 체감 용량이 작다고 생각할 수 있지만, 당연하게도 저장소 용량은 작업이 무엇이냐에 따라 무한정 커질 수 있으며, 이 공간이 로컬 저장소와 서버에 1:1 비율로 동시에 요구되게 된다. 기존 형상관리 툴이 원하는 파일 하나만 덜렁 받아서 작업하고 체크인할 수도 있는 것에 비하면 구조적으로 로컬과 원격, 총 2배수 공간을 사용하도록 설계되어 있다.
5. 서버 호스팅 및 저장소
5.1. 서비스식 Git 저장소
- GitHub: git이 유명해지면서 자유 소프트웨어의 성지로 떠올랐다. GitHub에 대한 자세한 사항은 해당 항목 참조.
- Bitbucket: Github의 비공개 프로젝트 기능이 유료였을 시절에는 "비공개 프로젝트가 필요한데 유료라 쓰기 애매하다 + 팀원이 몇 명 안된다" 같은 상황이라면 괜찮은 대안이 될 수 있었다.[6] Confluence, JIRA 등으로 유명한 Atlassian의 서비스로 5명[7] 이하가 참여하는 프로젝트라면 비공개 프로젝트도 무료로 생성 가능하다.
- GitLab - 인원수에 관계 없이 무제한으로 무료 비공개 프로젝트 생성이 가능하다.
- Azure DevOps (Visual Studio Online) - 저장소를 만들 때 기존 TFS 방식과 git 중에서 선택할 수 있다.
5.2. 자체 호스팅
외부에서 제공되는 서비스 형태가 아닌, 설치형 Git 서버는 리눅스 서버라면 별다른 추가 프로그램 없이 리눅스의 기본 프로그램(SSH 등)과 배포본에 들어있는 패키지 만으로도 서버를 구동할 수 있다. 유닉스 계열 서버에서도 손쉽게 설정할 수 있다.윈도라면 마이크로소프트의 Azure DevOps(구 Team Foundation Server)를 통해 Git 서버를 구성하여 사용할 수 있다. 서버 자체에서 기존 TFS와 git 방식을 동시에 지원한다. 다만 MS에서 제공하는 서버를 사용하기 싫다면 간단한 대안이 없었는데, GitBucket이라는 JVM 기반에 Scala로 GitHub를 흉내내어 작성된 오픈소스 프로그램이 등장했다. JVM 구동으로 메모리를 많이 먹는 단점을 제외하면 HTTP는 물론 SSH와 메일 알림 같은 여러 서버 기능을 자체적으로 지원하며, GitHub의 상당히 많은 기능을 매우 비슷하게 구현해 놓았기 때문에 GitHub을 쓰던 사람이라면 거의 그대로 사용할 수 있고, 그렇지 않더라도 GitHub처럼 매우 쉽게 쓸 수 있다는 장점이 있다.
6. 클라이언트
Git을 사용하는 방법은 많다. CLI로 사용할 수도 있고 GUI를 사용할 수도 있다. 이 책에서는 Git CLI 사용법을 설명한다. Git의 모든 기능을 지원하는 것은 CLI 뿐이다. GUI 프로그램의 대부분은 Git 기능 중 일부만 구현하기 때문에 비교적 단순하다. CLI를 사용할 줄 알면 GUI도 사용할 수 있지만 반대는 성립하지 않는다. GUI를 사용하고 싶더라도 CLI가 기본으로 설치되는 도구이기 때문에 CLI 기준으로 설명하겠다. - Progit의 CLI 챕터에서 발췌.[8]
일단 커맨드 프롬프트 방식 Git은 리눅스 바이너리 코드를 중심으로, 타 운영체제의 경우엔 호환성 레이어를 거쳐 실행하는 방식으로 제작되어 있다. 운영체제 포팅작업에서 일어날 수 있는 차이를 피할 수 있는 대신 비 리눅스 환경의 경우 용량이 상당히 크다는 약점이 있다.
CLI의 경우 윈도우, macOS, 리눅스를 전부 지원하며, 공식 사이트에서 내려받을 수 있다. 일부 GUI 툴들은 내부적으로 커맨드라인 툴을 호출하게 되어있기도 하다. Git 설치 후 구동 조건의 충족이나 꼬였을 때의 대처, 고급 버전 관리와 같은 기능[9]들은 CLI가 훨씬 편리하거나 CLI에서만 지원하므로 문제가 생기면 CLI 사용법을 찾아보는 것이 좋다.
Git 자체에도 gitk과 git-gui라는 GUI 툴을 기본 제공하고 있으나, 프롬프트에서 명령어를 쳐야 실행 가능하고 기능이 한정적이라 아래의 소프트웨어를 주로 사용한다.
윈도우/맥 진영은 SourceTree, 리눅스 진영은 SmartGit을 주로 사용한다. 또한 디자인과 기능 면에서 좋은 평가를 받는 GitKraken과 GitHub에서 직접 내놓은 GitHub Desktop도 있다. 윈도우 전용으로는 SubVersion 시절부터 유명했던 TortoiseGit가 있는데, 윈도우 탐색기와 연동되는 방식이라 사용하기 쉽고, SubVersion 시절에 많이 쓰였던 TortoiseSVN과 사용법이 거의 같기 때문에 SubVersion 쓰던 사람들이 넘어오기 좋다.
Visual Studio를 사용하는 환경이라면 git프로젝트를 사용하면 자동으로 내장된 자체 git GUI가 나타나므로 이걸 사용해도 상관없다. 물론 SourceTree 같은 외부 툴을 그대로 사용해도 된다. 메뉴에서 찾아 들어가려면 보기(V)->팀 탐색기(M) 단축키는 Ctrl+\\, Ctrl+M[10] 프로젝트 생성시 리포지토리 생성도 가능.
7. Git 사용법 배우기
인터넷에 공개된 자료가 매우 많다.- 간단히 보는 git 사용법
- 누구나 쉽게 이해할수 있는 Git 입문
- 생활코딩 - Git1, Git CLI - 버전관리, Git CLI - 브랜치 & 충돌, Git CLI - 백업, Git CLI - 협업, Git CLI - Cherrypick & Rebase, GitHub Pull Request, VSCode로 다루는 Git
- progit - GitHub의 CIO가 직접 쓴 책을 번역한 자료.
- 직접 해보는 Git branching
- MIT의 '잃어버린 한 학기' 강의
7.1. 타 형상관리 도구를 사용하던 사람이라면
타 도구를 사용하던 사람을 위한 소개 자료들도 제법 존재한다. 깃 관련 도움말을 아무리 봐도 영 감이 오지 않고 두렵다면 읽어볼만 하다. 기존 툴의 용어를 최대한 사용해서 쉬운 이해를 돕도록 작성되어 있다. 물론 기존 도구에 아예 없던 기능이면 어쩔 수 없다. (...)8. 기타
- 리누스 토르발스는 다른 버전관리 시스템인 Subversion을 아주 싫어하여, 대놓고 깐다. 구글에서 한 Git 강연
- Windows용 Git은 기본 설치 경로가
C:\Program Files내부인데, 폴더명Program Files에는 공백이 포함되어 있어 Git Bash 사용 시 에러가 발생할 수 있다. 설치할 때 이름에 공백이 포함된 폴더가 없는 경로를 지정해 주자.
- Git은 파일이나 커밋 등 모든 오브젝트를 SHA-1으로 해시한 식별자를 통해 관리한다. 그런데, SHA-1은 충돌 위험성을 넘어, 2017년에 구글에 의해서 SHA-1 전체의 해시 충돌이 밝혀졌기에 더 이상 안전하지 않고, 구글도 Git에 이 위험성을 전달하였다. 이에 토르발스는 "Git은 데이터를 해시하기만 하는 게 아니라, 거기에 타입과 길이 필드를 측량한다"며 동의하지 않았다. #
- the seed와 같은 위키 엔진과 원리가 상당히 비슷하다. 예를 들면 편집은 Commit, 편집 요청은 Pull Request, 토론은 이슈 트래커 등과 비슷하다고 할 수 있다. 심지어 자동 병합도 지원한다. 물론 시기상 위키보다 버전 관리 시스템들이 훨씬 더 옛날에 만들어졌기에 위키 엔진이 이를 따라했다고 보는게 옳다.
- git 은 /깃/ 으로 발음하는데, 이를 만든 토르발스가 이렇게 발음한다. 또한, git 의 어원이 get 이라서 /깃/이 맞다는 주장도 있다.
[1] 이 소스 코드도 자기 자신인 Git으로 관리되어 있다.[2] 다만 저장소 설명에 나와있듯 배포 전용 저장소이기 때문에 PR, 이슈 등을 받는 일반적인 저장소는 아니다.[3] 사이트는 www.bitkeeper.org이다. 오픈소스 전환 후 현재는 개발 중지 상태이다. 아래 설명 참조. 출처[4] Git이 아니더라도 DVCS(분산 버전관리 시스템)에 해당하는 Mercurial이나 Bazaar도 해당하는 사항이다.[5] 물론 프로그래밍을 업으로 삼거나 전공 수준 이상으로 학습하는 사람 중에서 Github 관리를 안 하는 사람은 드물지만, 입문자나 그동안 혼자 본인 컴퓨터의 로컬에서만 작업해본 사람들은 Git 사용법을 배우는 것 하나만으로도 골머리를 앓는 경우가 많다.[6] GitHub도 마이크로소프트가 인수한 뒤로는 팀원이 3명 이하인 비공개 프로젝트를 무료로 생성할 수 있도록 정책을 변경해서 단순히 비공개 프로젝트가 필요한 상황에서는 굳이 사용할 필요는 없어졌다.[7] 메일로 회원을 초대하면 8명까지 가능.[8] 강조 문구는 원문에서도 강조된다.[9] 특히 커밋 이후 이전 버전으로의 롤백 등[10] Ctrl 키를 누른 채로 \\과, M을 순서대로 누르면 된다.