Git 이해하기

본 내용은 Git 공식 매뉴얼 (1.시작하기)을 바탕으로 작성되었습니다.

Git 이해하기

자세히 알아보기 전에 Git과 GitHub가 무엇인지, 차이가 무엇인지 간단히 살펴보자.

Git 배경

• Linux 커널은 1991~2002 Patch와 단순 압축 파일로만 관리
• 2002년, BitKeeper라고 불리는 상용 분산 버전 관리 시스템 사용 시작
• 그러나 2005년, BitKeeper의 무료 사용이 재고됨 (BitKeeper는 상업회사였기 때문)

• 이것을 계기로 Linux 커널를 만든 Linus Torvalds와 커뮤니티 개발자들이 자체 도구로 Git을 개발
  

• Git의 목표
  • 빠른 속도
  • 단순한 구조
  • 비선형적인 개발(수천 개의 동시 다발적인 브랜치)
  • 완벽한 분산
  • Linux 커널 같은 대형 프로젝트에도 유용할 것 (속도나 데이터 크기 면에서)
    

Github

• Git : 분산 버전 관리 시스템(DVCS) 소프트웨어
• GitHub
  • Git에서 진행했던 각각의 내용들을 공유할 수 있게 공간을 제공하는 서비스
  • 가장 큰 Git 저장소 호스트

쉽게 이해하기 위한 비유를 해본다면,

• Git : 타임머신을 가지고 있는 요리사라면 GitHub는?
  • 그때 만든 내용과 그 타임머신 기능을 모두에게 공개/공유하는 것.
  • 세계 각지에 있는 나와 비슷한 타임머신을 가진 요리사들의 요리법을 볼 수도 있고,
    직접 내가 해당 요리 진행 중 타임머신을 활용해 요리하는 것에 참여할 수도 있는 것

버전 관리 시스템

위의 설명과 같이 Git(깃)이란 분산 버전 관리 시스템 중 하나이다. 분산 버전 관리 시스템은 버전 관리 시스템 중 하나이며, 이에 대해 알아보자.

• 버전 관리란? (출처: 위키피디아)
  • 동일한 정보에 대한 여러 버전을 관리하는 것
  • 변경 사항들에 숫자나 문자로 이뤄진 버전을 부여해서 구분
  • 소프트웨어 엔지니어링에서는 일반적인 소프트웨어 소스 코드만을 관리하는 내역을 주로 버전 관리라고 정의

• 버전관리 시스템(VCS, Version Control System)
  1. 로컬 버전 관리 (Local Version Control System)
     • 로컬 전용
     • DB 사용하여 파일 변경 정보 관리
       
       
  2. 중앙 집중식 버전 관리 시스템 (CVCS, Centralized Version Control System)
     • Client - Server 구조로 파일 관리 서버가로 별도로 존재
     • 클라이언트가 중앙 서버에서 파일을 받아 사용(Checkout)
     • 수정할 파일만 받아서 수정한 후, 중앙 서버에 업로드
       
     • 장점
       • 중앙 서버만 관리하면 되기에 편리
       • 간단한 방법으로 다른 개발자와 협업 가능
     • 단점
       • 서버에 문제가 발생되면 모든 업무가 중단 불가, 백업 불가
         
     • 시스템 종류: CVS(Concurrent Version System), SVN(Subversion), P4V(Perforce) 등
       
       
  3. 분산 버전 관리 시스템 (DVCS, Distributed Version Control System)
     • 중앙 집중식 버전 관리 시스템처럼 서버에 파일 저장
     • 단순히 파일의 마지막 스냅샷을 Checkout 하지 않고, 저장소의 파일을 히스토리와 더불어 전부 복제(Clone)
       • 프로젝트 전체를 로컬에 다운로드한 뒤, 작업
         
     • 장점
       • 중앙 서버에 접속하지 않은 상태에서도 코드 작업 가능
       • 안정성면에서 좋음
         • 중앙 서버에 문제가 발생되더라도 로컬에 다운로드한 내용이 존재
       • 로컬을 수정하기 때문에 다른 사람들과 충돌X
         • 최종적으로 서버에 다시 올릴 때만 신경을 써주면 됨
     • 시스템 종류: Git, Mecurial, Bazaar, Darcs
       
       

로컬(Loval VCS)	중앙 집중(CVCS)	분산(DVCS)

Git 기초

Git을 사용하기 위해서 알아야 할 개념들을 알아보자.

Commit

• Commit이란?
  • 출처: 위키피디아
    • 데이터베이스에서 영구적인 변경을 확정하는 일
    • RDBMS에서 트랜잭션을 종료하고 다른 사용자에게 변경된 모든 사항을 보이도록 만드는 문
    • 저장소에 소스 코드의 일부의 최신 변경사항을 추가함으로써 이러한 변경사항을 저장소의 최상위 리비전(head revision)의 일부분으로 만들어주는 것
      
      
  • 출처: 국어사전
    • 스마트 드라이브 따위와 같은 캐시 기억 장치에다가 디스크에 정보를 저장하라고 알려 주는 명령어.
    • 이때 캐시 기억 장치에서는 변경된 내용만 디스크에 저장한다.

• Git-Commit
  • Git Manual(도움말) : Record changes to the repository
  • 즉, 저장소에 변경 내용을 기록하는 것 = 버전 업데이트/등록

무결성

• Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학이 Checksum이며, 이 Checksum을 통해 무결성 확인 및 관리

• Git의 Checksum
  • 파일이나 디렉토리 구조를 기반으로 계산
  • SHA-1 Hash 사용 (40자 길이의 16진수 문자열)
  • 예) 24b9da6552252987aa493b52f8696cd6d3b00373

• Git은 모든 것을 저장하기 전에 Checksum 수행, Hash값으로 관리하여 무결성 확보
  • Git 모르게 파일/디렉토리 내용 변경 불가
  • Git 모르게 전송 중 정보 손실, 파일 손상 발생 불가 (It’s impossible to change the contents of any file or directory without Git knowing about it.)
    (You can’t lose information in transit or get file corruption without Git being able to detect it.)

• Commit ID 또는 Commit hash
  • Commit할 때에 Checksum하여 중복 확인 및 저장하기에 위와 같이 부름
  • GitHub에서 파일을 보면 commit xxxxxxxxx…. 가 이에 해당
  • 실제로 Git은 파일을 이름으로 저장하지 않고, 해당 파일의 Hash 값으로 저장

로컬에서 실행

• 거의 모든 명령이 로컬 파일과 데이터만 사용
  • 네트워크에 있는 다른 컴퓨터는 필요 없음
  • 오프라인 상태이거나 VPN에 연결하지 못해도 작업 가능
  • 다른 VCS 시스템에서는 파일 편집은 가능하지만, DB에 접근할 수 없기에 commit은 불가

• 명령어 처리 속도가 굉장히 빠름
  • 프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령이 순식간에 실행
  • CVCS은 네트워크의 속도에 영향을 받음
  • 예) 프로젝트 히스토리 조회
    • Git: 서버없이, 로컬 DB에서 조회 -> 빠름
    • CVCS: Remote 서버 접근하여, 예전 버전 가져와 비교

Snapshot

• “데이터를 스냅샷의 스트림처럼 취급”
  • 데이터를 파일 시스템 스냅샷의 연속으로 취급
  • 크기가 아주 작음 (작은 파일 시스템)
  • Commit하거나 프로젝트의 상태를 저장할 때, 파일이 존재하는 그 순간이 중요
  • 파일이 달라지지 않았다면 성능을 위해 파일을 새로 저장하지 않음

  • 단지 이전 상태의 파일에 대한 링크만 저장
    
    

  • 다른 시스템(CVS, Subversion, Perforce, Bazaar 등)은?
    • 델타 기반 버전관리 시스템
    • 각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리
      

• 차이 비교
  • Git
    • 저장소에 Commit할 때, 저장소에 있는 정보와 업데이트된 파일과의 차이를 확인하여 저장소에 업데이트 델타만 업로드
    • Commit할 때, 부모 Hash도 참조하여 저장하기에 수정한 히스토리도 확인/관리 가능
  • 일반적인 다른 시스템
    • 다른 사용자와의 충돌이 발생하여, 업데이트 내용이 덮어씌워질 수 있음
    • Commit 전에 업데이트하여 최신 상태로 유지해야 함

Only Add

• Git에서 작업할 때, Git 데이터베이스에 거의 모두 데이터 추가만 수행
• 되돌리거나 데이터를 삭제하긴 어려움
  • 일단 스냅샷을 Commit하고 나면 데이터를 잃어버리기 어려움
    (특히 정기적으로 데이터베이스를 다른 리포지토리에 푸시하는 경우)
  • 하지만 다른 VCS처럼 Git도 Commit하지 않으면 변경사항을 잃어버릴 수 있음
• 때문에 프로젝트가 심각하게 망가질 걱정 없이 매우 즐겁게 여러 가지 실험 가능
• 데이터를 어떻게 저장하고 손실을 어떻게 복구하는지는 다음 포스트 참고

State

State에 대해 간단히 알아보자. 자세한 설명은 다음 글(포스트)에서 다둘 것이다.

• State: Modified, Staged, Committed - 3가지 상태
  • Committed: 데이터가 로컬 데이터베이스에 안전하게 저장된 상태
  • Modified: 수정한 파일을 아직 로컬 데이터베이스에 Commit하지 않은 상태
  • Staged: 현재 수정한 파일을 곧 Commit할 것이라고 표시한 상태

• Sections(구성요소, 단계): Git Directory, Staging Area, Working Tree(Directory)
  • Git Directory
    • Repository
    • 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳
    • Git 디렉토리는 지금 작업하는 디스크에 위치
    • Git의 핵심이며, 다른 컴퓨터에 있는 저장소를 Clone할 때 만들어짐
  • Working Tree
    • 프로젝트의 특정 버전을 Checkout한 것
    • Git Directory 안에 압축된 데이터베이스에서 파일을 가져와서 Working Tree 생성
  • Staging Area
    • 곧 Commit할 파일에 대한 정보를 저장
    • Git Directory에 위치
    • 단순한 파일이고
    • Git에서 “Index”라는 용어로 사용됨
• State와 Sections
  • Git Directory 있는 파일들은 Committed 상태
  • 파일을 수정하고 Staging Area에 추가하면 Staged
  • Checkout하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified
• Git Workflow
  1. Working Tree에서 파일을 수정
  2. Staging Area에 파일을 Stage해서 Commit할 스냅샷 생성 (모든 파일 또는 선택하여 추가)
  3. Staging Area에 있는 파일들을 Commit해서 Git 디렉토리에 영구적인 스냅샷으로 저장

(State에 대한 자세한 내용은 다음 포스트(3. Git의 기초) 참고)

추천 참고 사이트

• Git 매뉴얼
• 누구나 쉽게 이해할 수 있는 Git 입문
• Coding Groot 블로그