Git 기초

MoonGoon·2024년 8월 4일
0

모각코

목록 보기
18/19

VCS 버전관리 시스템

파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 불러올 수 있는 시스템

VCS 종류

  • 로컬 버전관리 (LVCS - Local VCS)

로컬 컴퓨터의 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리.

하나의 로컬 컴퓨터에서 파일을 관리하는 방식

  • 중앙집중식 버전관리 (CVCS - Central VCS)

다른 개발자들과의 협업을 위해 개발됨

파일을 관리하는 서버가 별도로 존재하고, 클라이언트가 중앙 서버에서 파일을 받아 사용

  • 장점
    • 모두 누가 무엇을 하는지 알 수 있다.
    • 관리자가 누가 무엇을 할지 꼼꼼하게 관리 가능
    • 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기 훨씬 쉽다.
  • 단점
    • 중앙 서버가 다운될 경우, 그 동안 아무도 다른 사람과 협업이 불가능하다.
    • 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다.
    • 모든 버전 관리 관련 동작은 서버에서 처리되어야 하므로 서버의 부하가 크다.
    • 서버가 죽거나 장애가 발생하면 버전 관리가 이루어지지 않는다.
    • 오프라인 상태에서는 버전 관리 시스템을 사용할 수 없다.
    • 모든 버전 관리 관련 동작은 적어도 한 번 서버를 경유해야 하므로 속도가 느리다. 하다못해 로그를 보는 것 조차 서버에서 데이터를 받아와야 하므로 느리다.
    • 서버에서 데이터가 망가지거나 삭제되면 복구하기 매우 어렵다.
  • 분산 버전관리 (DVCS -Distributed VCS)

클라이언트는 단순히 파일의 마지막 스냅샷을 checkout 하지 않는다.

저장소를 히스토리와 더불어 전부 복제

서버에 문제가 생기면 이 복제물로 다시 작업 가능

클라이언트 중 아무거나 골라도 서버 복원 가능

  • 단점
    • 복잡함
    • 동기화 문제

snapshot (스냅샷)

특정 시점에서의 파일, 폴더 또는 워크스페이스의 상태

스냅샷을 통해 특정 시점에 어떤 파일에 어떤 내용이 기록되었는지, 폴더 구조는 어땠는지, 어떤 파일이 있었는지 등의 저장소의 모든 정보 확인 가능

델타 방식

각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리

  • 각 버전별로 변경점 저장
    • e.g. 버전 생성시 각 파일 전체를 저장함. 이후 각 버전별로 이전의 변경점만 저장함.
  • 따라서 특정 버전의 파일을 보려면 Version 1 → Version 2 → … → Version n 까지의 변경사항을 순서대로 적용해야 하므로 시간이 많이 걸릴 수 있다.

스냅샷 방식

시간순으로 프로젝트의 스냅샷 저장

  • 파일의 최종 상태를 직접 저장
    • e.g. 버전 3에 파일 A, B, C 존재하고, 버전 4에서 파일 B가 B1, C가 C1으로 변경되었으면, 버전 5의 스냅샷은 A, B1, C1인 최신 버전이 저장됨.
  • 따라서 특정 버전은 해당 버전의 파일을 직접 접근하면 되기 때문에 빠르게 접근 가능

git

Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여긴다. 파일이 달라지지 않았으면 파일을 새로 저장하지 않음. 단지 이전 상태의 파일에 대한 링크만 저장

거의 모든 명령을 로컬에서 실행

  • 프로젝트 히스토리를 조회할 때 서버 없이 조회함. (로컬에 히스토리가 다 있기 때문)
  • 네트워크 연결 없이 커밋 가능(로컬 저장소이기 때문)

Git의 무결성

  • Git은 파일을 저장하기 전 항상 체크섬을 구하고, 체크섬으로 관리
  • SHA-1 해시를 사용하여 체크섬을 만든다.
  • Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장

Git은 데이터를 추가만 한다

  • 되돌리거나 데이터를 삭제할 방법 없이 뭘 하든 Git 데이터베이스에 데이터가 추가 된다.

세 가지 상태

  • Git 디렉토리 : 커밋되어 버전을 관리하는 파일들이 위치하는 영역
    • Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳
    • 다른 컴퓨터에 있는 저장소를 clone 할 때 git 디렉토리 생성
  • 워킹 디렉토리 : Git이 추적중인 파일들이 위치하는 영역
    • 프로젝트의 특정 버전을 Checkout 한 것.
    • 작업한 파일들이 저장되는 곳
  • Staging Area : 커밋할 준비가 된 파일들이 위치하는 영역
    • Git 디렉토리에 존재.
    • 단순한 파일, 곧 커밋할 파일에 대한 정보를 저장

파일 상태 변화

  • staged : 수정한 파일들 중 commit 할 것이라고 표시한 상태
  • tracking : 버전 관리를 위해 해당 파일을 추적하는 것
  • modified : 파일 내용이 수정된 상태

  • Untracked : 관리 대상이 아닌 파일, 즉 추적이 안된 상태 (Git으로 버전관리를 하지 않는 상태)
  • Unmodified : 파일 내용이 수정이 안 된 상태
  • Modified : 파일 내용이 수정 된 상태
  • Staged : Staging Area에 반영된 상태

Git 개체 (Object)

Blob

파일의 내용을 담고 있다.

Tree

파일의 이름을 저장

파일 여러 개 한꺼번에 저장 가능

Git은 모든 것을 Tree와 Blob 개체로 저장

디렉토리 단위, 하위 디렉토리가 있을 경우 해당 tree는 하위 tree로 하위 디렉토리 정보를 가진다.

Commit

commit도 내부적으로는 개체 (object)이다.

commit 하는 tree, author, commiter 가 저장됨

tree {해시값}으로 나타남

해당 tree에 가면 staging 된 file 정보인 blob {해시값} {이름} 으로 저장되어 있음


출처 - 지옥에서 온 git

이후 파일 생성 or 수정 or 변경 등을 통해 새로운 커밋을 생성하면


출처 - 지옥에서 온 git

이전 commit을 parent로 하는 객체가 추가됨

index

해시로 저장된 object 파일의 이름이 무엇인지 가리킴

object

  • 파일 이름이 달라도 내용이 같으면 같은 object를 가리킴
profile
Swift 개발자를 희망합니다

0개의 댓글