var i_able

Snapshot과 diff / patch / delta

diff

말 그대로 차이(difference)이다. diff 명령어를 이용해 두 디렉토리/파일 간의 차이를 구할 수 있고, 그 차이를 파일로 생성해 저장한다. 이 때의 파일이 바로 patch 파일이다. 이러한 patch를 이용해 다른 시스템의 파일에 적용할 수 있다. (그래서 이름이 패치군)

delta는 아마 차이 그 자체, 즉 변경된 부분의 데이터를 말하는 듯하다. diff를 통해 패치 파일을 생성하는 과정은 델타들을 패치 파일에 저장하는 과정이라고 받아들였다.

diff를 이용하는 예를 들어보자.

wlqrkrhtlvek 라는 이름의 파일에 대한 작업을 한다고 하자. 우선 작업 전 이 파일을 복제해 wlqrkrhtlvek.orig 라는 파일을 생성한다. 이때의 파일은 원본이 되므로 절대 수정해선 안 된다. 그 후 파일에 대해 작업을 수행한다.

작업을 완료하면:

diff wlqrkrhtlvek.orig wlqrkrhtlvek > wlqrkrhtlvek.diff 를 실행해 원본과 작업 파일간의 차이를 wlqrkrhtlvek.diff에 저장한다.

이렇게 생성된 wlqrkrhtlvek.diff 파일이 바로 패치 파일이다(.patch를 사용하기도 함.)

여기서 wlqrkrhtlvek.orig에 wlqrkrhtlvek.diff를 적용하면 wlqrkrhtlvek와 같은 결과가 되는 것이다.

참고: https://kldp.org/node/28938

20년 전 글인데 설명을 되게 잘하신 것 같다.

Snapshot

버전 관리 시스템마다 데이터를 관리하는 방식이 다르다. SVN(subversion)과 같은 시스템들은 델타 방식을 사용하는 방면, 깃은 스냅샷 방식을 사용한다.

델타 기반 버전 관리 시스템은 말 그대로 델타, 차이를 저장한다. 파일이 생겨난 시점에는 파일 전체를 저장하고, 이후 시간순으로 파일 집합을 관리하며 파일이 변경되면 그 시점과 처음 상태의 차이를 저장한다.

아래의 사진에서 예를 들면 파일 C의 Version 5는 Version 1 + 델타1 + 델타2 +델타3 으로 계산하는 것이다.

언뜻 보기엔 저장공간도 절약되고 좋아보이지만, 이 델타가 무수히 많아진다고 생각하면 이를 계산하는 것은 비효율적일 수 있다.

반면 스냅샷 방식을 쓰는 깃에서는 특정 시점에서 모든 파일의 '스냅샷'을 저장한다. 지금은 이 스냅샷을 파일들의 정보를 저장한 객체라고 이해하겠다. 깃에서는 시간순으로 '프로젝트의 스냅샷'을 저장하며, 데이터를 파일 시스템 스냅샷의 연속으로 취급한다. 그렇다는 건 버전이 바뀔 때마다 모든 파일을 포함한 스냅샷이 생긴다는 얘긴데, 너무 부담스럽지 않을까? 그렇지 않다! 변경된 부분이 없는 파일은 새로 저장되지 않고 이전 버전에 대한 링크만 저장한다. 이를 통해 깃은 다른 VCS와 구분되게 된다.

https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Git-%EA%B8%B0%EC%B4%88

https://www.slideshare.net/andabi/git-16126636

로컬 공간과 파일의 상태

로컬 공간

로컬에서 작업할 때, 세 가지 '공간'이 존재한다. (공간이 정확한 표현일 지는 모르겠지만 편의상 칭하도록 하겠다.)

1. Working Directory
   파일을 modify하는 곳이다. 여기서 개발자는 코드를 수정, 생성하는 등의 작업을 한다.
2. Staging Area
   파일을 modify 한 후 Staging Area에 파일을 추가한다. 이때 '파일이 추가된다'고 표현했지만, 파일 자체는 작업 디렉토리에 남아있으며, 파일의 '스냅샷'이 생성되어 Staging Area에 추가된다. 즉 Staging Area에 추가한 시점의 상태가 저장되는 것이다.
   (그냥 커밋할 거라고 표시가 된 상태다! 라고 하는데 Staging Area가 정확히 어떤 의미인진 더 공부가 필요할 것 같다.)
   이 스냅샷은 commit 할 준비가 됐다.
3. Git Directory (Repository)
   commit을 하면 Staging Area에서 대기 중이던 변경 사항이 로컬 레포지토리에 저장된다. 이후 push를 통해 원격 레포지토리에 로컬의 변경 사항을 저장할 수 있다.

파일의 상태

1. Modified
   파일이 수정 된 상태. Stage나 Commit을 하지 않은 상태. Working Directory에 존재
2. Staged
   파일이 Stage 된 상태. Staging Area에 존재
3. Committed
   파일이 Commit 된 상태. 로컬 저장소에 잘 저장된 상태. Git Directory에 존재

https://velog.io/@chillihc/Git-%EA%B0%9C%EB%85%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

https://velog.io/@kkh30123/GIT

Upstream / Downstream

업스트림과 다운스트림은 상대적인 개념으로, 업스트림에서 다운스트림으로 흐르는 관계가 형성된다.

Upstream

보통 원본 레포지토리로, 작업의 기준점이 된다. 업스트림을 추적하여 프로젝트의 진행과 동기화한다.

push, pull를 '당하는' 레포지토리

Downstream

주로 특정 작업을 위한 레포지토리. 업스트림의 내용을 받아와 새로운 기능을 추가하는 등의 추가 작업 진행

push, pull를 '하는' 레포지토리

https://pers0n4.io/github-remote-repository-and-upstream/

개인적으로 검색과 함께 공부하여 잘못된 내용이 있을 수 있음에 양해를 구합니다!

Git은 컴퓨터 파일의 변경사항을 추적하고 여러 사용자들의 작업을 조율하는 분산 버전 관리 시스템(DVCS)이다.

여기서 분산 버전 관리 시스템은 뭘까? 그 전에 버전 관리는?

버전 관리 시스템(VCS)은 컴퓨터 파일의 모든 변경사항을 시간에 따라 기록했다가, 특정 시점의 버전을 꺼내올 수 있는 시스템이다. VCS는 소프트웨어의 소스 코드뿐 아니라 거의 모든 종류의 파일의 버전을 관리할 수 있다. 쉽게 말해서 텍스트 문서를 작성할 때 VCS를 이용하면, 내용을 추가/삭제한 후 임시저장을 할 때마다 새로운 파일(정확히는 스냅샷)이 생성된다고 볼 수 있다.

버전 관리에는 크게 세 가지 종류가 있다.

로컬 버전 관리 시스템(Local VCS)은 단순한 형태의 VCS로, 단일 사용자가 사용한다. 로컬에 버전 데이터베이스를 생성해 파일의 버전 정보를 관리한다.

중앙 집중식 버전 관리 시스템(CVCS)은 중앙의 서버가 파일 버전을 관리하고, 클라이언트들이 파일을 받아와 checkout(최신 변경사항 가져오기)할 수 있다. 여러 사용자가 함께 작업할 수가 있다. 그러나 서버에 모든 파일 정보가 있어, 서버가 다운되거나 하는 일이 발생하면 클라이언트들이 가지고 있는 스냅샷을 제외하고는 복구할 방법이 없다. 또 특정 버전을 가져오는 것이 일반적으론 불가능하며, 서버에서 해당 버전을 커밋 번호를 이용해 업데이트해야 가능하다. 

분산 버전 관리 시스템(DVCS)은 서버와 클라이언트를 동기화한다. CVCS와 달리 클라이언트도 로컬 저장소를 가지며, 서버의 히스토리를 전부 복제한다. 로컬에서의 변경 후 푸시(push)를 하면 서버로 전달할 수 있는 것은 같으나, 서버에 문제가 생겨도 로컬의 복제물로 서버 복구가 가능하다는 장점이 있다. 또 CVCS와 달리 로컬 저장소가 있어 개발자가 원하는 특정 버전을 가져올 수 있다.

이런 버전 관리 시스템을 이용하지 않고 단순히 파일을 복사하여 버전을 관리하는 원시적인 방법을 쓸 수도 있으나, 파일을 실수로 삭제하거나 잘못 고치는 문제가 발생할 수 있다. 또한 VCS는 변경된 부분(patch)만을 저장하는 반면, 이 방법은 파일 전체를 저장해 저장공간 등의 관리 비용이 커질 수 있다.

따라서 효율적인 관리를 위해선 버전 관리 시스템을 이용하는 것이 현명하다.

그 중에서도 DVCS는 분산 개발 및 협업 등의 측면에서 CVCS에 비해 장점이 많아 많이 이용된다.

깃은 속도, 단순한 브랜치 생성(브랜치를 중요하게 다룸), 협업의 용이성의 측면에서 강점을 가져 개발자들이 가장 많이 쓰는 버전 관리 시스템 중 하나다.

출처: https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80%3F