SnapShot
SVN 에서 사용하는 델타 방식, Git에서 사용하는 스냅샷 방식
델타 방식은 각 파일이 생겨난 버전에 해당 파일 전체가 저장이 되고, 이후 이 파일에 수정이 가해질 때는 그 변경점들이 저장이 됨
-> ex) 버전 5에서 C 파일의 내용은 버전 1의 원본으로 부터 1,2,3 변화가 누적된 걸로 계산이 됨
반면 스냅샷은 새로운 버전이 만들어 질 때, 해당 버전의 각 파일이, 최종 상태 그대로 저장이 되어있음
-> ex) 버전 5의 경우, 4와 비교했을 때 A파일에는 변화가 없으니까 버전 4에서의 A파일을 그대로 연결해서 가져오고, 변화가 있는 B파일과 C파일은 이 둘 각각의 최종 파일 내용이 그대로 저장되어있는 것
만약 커밋이 몇만개가 있는 Repository를 다룬다고 가정
-> 이를 델타 방식으로 다룬다면, Git에서 브랜치를 바꾸든 어떠한 작업을 할 때마다 각 파일들을 그것이 처음 만들어진 시점부터 변경사항들을 일일히 더해가지고 현재 내용을 계산해야 함
-> 관리 역사가 길수록 되게 느려짐
-> 반면 스냅샷 방식으로 다룬다면, 그냥 현재 시점에 각 파일들이 full로 저장되어있기 때문에 편함
분산 버전 관리
CVS나 Subversion 등의 VCS는 원격서버에 모든 관리 내역들이 저장됨
-> 여기에 참여하는 인원들의 컴퓨터, 즉 로컬에는 중앙에서 현 버전 것으로 다운받은 파일들로만 작업이 가능
-> 이는 원격 저장소에 의존적, 예를 들어 인터넷 연결이 불안정하다면 로컬에서 할 수 있는 것이 제한 될 것
반면 Git에서는 Download Zip이 아닌 git clone을 통해 받아오면 로컬에 파일들 뿐 아니라, 전체 Git 커밋이랑 브랜치들까지 받아짐
-> 인터넷 연결 상태와 상관없이 로컬에서 자유롭게 작업을 할 수 있음
-> 모든 구성원이 Git의 상태까지 공유하기 떄문에, 원하는 때에 프로젝트를 push와 pull로 동기화하면서 협업이 가능
Git의 3가지 공간
Git에서는 파일의 상태를 3가지로 분류
바뀐 내용들이 모두 commit이 된 상태(어떠한 버젼안에 들어있는 상태) -> Repository
새로 추가하거나, 수정 사항이 만들어지면 이것들은 Working Directory에 위치한 상태
-> 여기 안에서 Untracked, Tracked 상태로 나뉨
-> Untracked는 .gitignore에 추가된 파일이거나 새로 만들어진 파일
-> 즉 add가 되본적이 없는 파일
Staging Area는 커밋이 되기전 준비상태라고 생각
파일 삭제 및 이동, reset
그냥 우클릭으로 삭제 후 그 내역을 git add .를 해야지만 deleted로 처리가 됨
-> 이후 복원을 위해 git reset --hard
삭제 후 add 과정없이 바로 commit을 통해 반영하기 위해선느 rm 사용
단순히 이름 변경 뒤 확인했을 때
add 이후
mv를 사용하여 이름을 변경한 경우
-> 바로 수정사항이 Staging Area 에 위치
Staging Area에서 다시 Working Directory로 반환
커밋을 위해 Staging Area에 올렸지만, 특정 파일은 나중에 커밋하기 위해 Staging area에서 빼는 경우
git restore --staged (파일명)예를 들어 pumas.yaml 파일을 제외하고 싶은 경우
-> git restore --staged pumas.yaml
--staged를 빼면 working directory에서도 제거
-> 변화 상태 자체를 되돌리고 싶은 경우
-> 그냥 restore인 경우 repository 상태로 되는 것!
git reset 종류
--soft: repository에서 staging area로 이동--mixed (default): repository에서 working directory로 이동--hard: 수정사항 완전히 삭제
hard의 경우 수정 사항을 Working Directory에서도 날려버리는 경우
mixed의 경우는 디렉토리에 남겨두기에 파일 자체는 변하지 않음(수정 내용이 취소되지 않음)
