[문과 코린이의 IT 기록장] Git 심화 (VCS vs Git, Git에서 파일들이 거치는 상태 (Git의 3가지 공간), HEAD, fetch vs pull)
1. VCS vs Git
이전의 VCS(CVS, Subversion)들과 차별되는, Git의 강점은?
1) 스냅샷 방식 사용
- VCS에서 사용하는 방식 : 델타 방식
: 각 파일이 생겨난 버전에 해당 파일 전체가 저장이 된다. 그리고 이후 그 파일이 수정이 가해질 때마다, 새로운 수정 파일이 저장이 된다.
- Git에서 사용하는 방식 : 스냅샷 방식
: 새로운 버전이 만들어질 때마다, 각 파일이 만들어진 최종 상태 그대로 저장되어 있다.
: 저장 되는 방식도 용량을 크게 차지하지 않는 효율적인 방식으로 활용되고 있다.
* commit이 몇만개가 있는 repository
- 델타 방식으로 다룰 경우
: git에서 브랜치를 바꾸는 등 어떤 행동을 할 때마다, 각 파일의 처음 만들어진 시점부터 변경사항을 모두 되돌아가 더해서, 현재 내용을 계산해 내야 한다. 따라서, 관리 역사가 긴 파일일 수록, 더욱 더 느려지게 될 것이다.
- 스냅샷 방식으로 다룰 경우
: 현 시점의 파일들이 한번에 저자오디어 있기 때문에, 굉장히 빠르게 처리될 수 있다.
2) 분산 버전관리 시스템 사용
- VCS에서 사용하는 시스템 : 중앙집중식 버전 관리
: VCS 원격 서버에 모든 관리 내용들이 저장되며, 로컬 컴퓨터들은 항상 원격(중앙)컴퓨터에서 현 버전으로 다운받아야 작업이 가능하다. 즉 VCS방식은 원격 저장소에 의존적이라는 단점을 가진다.
ex. 인터넷에 문제가 발생했을 때, 로컬 컴퓨터에서 할 수 있는 것들이 제한적이다.
- Git에서 사용하는 시스템 : 분산 버전관리
: Git은 원격 컴퓨터에 있는 내용들을 Zip 다운로드로 받을 수도 있지만, clone 명령어를 통해서 파일 + Git 커밋 + 브랜치까지 받아올 수도 있다.
: 즉, 모든 구성원들이 Git의 상태까지 공유하기 때문에, 각자 편한대로 작업하다가 프로젝트를 psuh 및 pull 해가면서 협업을 해 나갈 수 있으며, 인터넷 연결상태와 상관없이 로컬에서 자유롭게 적용이 가능하다.
* 서버에 문제가 생길 경우, 아무 클라이언트의 복제물로 서버를 복원할 수 있음. (Git에서는 클라이언트가 서버를 몽땅 복사해가기 때문)
2. Git에서 파일들이 거치는 상태 (Git의 3가지 공간)
* Repository는 .git directory라고도 불림 (커밋된 상태)
1) 파일의 삭제 및 이동
ex. tigers.yaml 파일을 삭제했을 경우
$git status
# 해당 삭제 파일이 add되지 않았다는 표시가 뜬다
$git add .
$git status
# git add . 를 하면 해당 표시가 사라진진다. (Staging area상태로 간 것)
=> 파일의 삭제와 git add . 를 한번에 수행하는 방법
$git rm 파일명
# 파일 삭제 + git add . 과정을 한번에 진행한 상태
# git status로 보면 정상적으로 staging area에 들어간 것을 확인 가능하다.
2) 파일명 변경
ex. tigers.ymal파일명을 zzmtigers.yaml으로 변경했을 경우
$git status
# 파일명 변경 후 git status를 했을 경우, tigers.yaml파일이 삭제되었고, zzmtigers.yaml파일이 새로 생성되었다고 나옴.
$git add .
$git status
# 해당 파일명이 변화된 것을 제대로 인식하게 됨.
=> 파일명 변경과 git add . 를 한번에 수행하는 방법
$git mv 변경전파일명 변경후파일명
# 파일명 변경 + git add . 과정을 한번에 진행한 상태
# git status로 보면 정상적으로 staging area에 들어간 것을 확인 가능하다.
3) 파일을 staging area에서 working directory로 되돌리는 방법
$git restore --staged (파일명)
--staged를 빼면 working directory에서도 제거 (변화 상태 자체를 제거하기 위함)
4) reset의 세 가지 옵션
a. --soft : repository에서 staging area로 이동
b. --mixed(default) : repository에서 working directory로 이동
c. --hard : 그 내역 자체를 지워버림. 즉 수정사항 완전히 삭제함.
3. HEAD
git의 HEAD란? : 현재 속한 브랜치의 가장 최신 커밋
1) HEAD를 사용하여 checkout으로 앞뒤 이동해보기
* checkout의 대부분의 기능들이 switch 및 restore로 대체되고 있다. 그러나 이것만으로 할 수 있는 것들 또한 존재한다.
* HEAD를 사용하여 checkout으로 앞뒤를 이동하게 되면, histroy는 그대로 두고 파일들의 상태만 변경시킬 수 있다.
(이는 reset 및 revert랑 다르다. - reset은 과거로 가면서 그 이후의 것을 모두 없애는 것이며, revert는 과거의 것을 다시 뒤로 이어붙이며 되돌리는 것이다.)
$git checkout HEAD^
# ^ 또는 ~갯수만큼 이전으로 이동하게 된다.
# 사용 예시 : git checkout HEAD^^^, git checkout HEAD~3
# 커밋 해시를 활용해서도 이동이 가능하다. ex. git checkout (커밋 해시)
이는 익명의 새로운 브랜치 하나가 잠시 만들어진 것이라고 볼 수 있다.
이와 같이 checkout을 활용해 몇 단계 전의 시점으로 돌아가서, 그 시점부터 'git swtich -c 브랜치명'를 활용해 새로운 브랜치를 만들어낼 수 있다.
브랜치 이동을 한 단계 되돌리는 방법은?
$git checkout -
# 이동을 한 단계 되돌리는 방법
checkout되었던 상태에서 기존 브랜치로 돌아오기 위해서는 (해당 HEAD 브랜치 삭제를 위해서는)?
$git switch 브랜치명
# 기존 해당 브랜치명을 입력해 이동해서, HEAD를 삭제한다.
2) HEAD를 사용하여 reset하는 방법
HEAD를 사용해서 reset을 진행할 수 있다. (기존에는 git log에서 해당 커밋의 해시를 알아내고, reset을 했어야함)
$git reset HEAD (원하는 단계) (옵션)
# ex. git reset --hard HEAD~2
# 두 단계가 사라진 것을 확인할 수 있음
4. fetch vs pull
- fetch : 원격 저장소의 최신 커밋을 로컬 저장소로 가져오기만 함. (다운을 받아오기만 함)
- pull : 원격 저장소의 최신 커밋을 로컬 저장소로 가져와 + merge 또는 rebase를 하는 것. (fetch의 과정을 포함함)
* fetch는 원격 저장소에 변화가 생겼을 경우, 그것을 내 컴퓨터(로컬)로 가져와서, 현재 브랜치에 merge 또는 rebase하기 전 살펴보는 과정에서 사용된다.
* fetch를 통해 뻗어나온 보이지 않는 브랜치를 생성한 다음, 그리로 이동해 결과물을 임의로 보고자 할 때 사용할 수 있다.
- 원격 저장소에서 변경되고 커밋된 파일 내용을 확인하는 방법
$git fetch # 원격 저장소의 최신 커밋을 가져오기
$git checkout origin/main
# 임시 브랜치로 이동함으로써, 적용되었을 때의 결과물을 볼 수 있음 (실제 pull X)
$git switch main
$git pull
# 최종적으로 main 브랜치에서, 원격 저장소의 최신 커밋 내용을 저장시키기
- 원격 저장소에서 생성한 새 브랜치를 확인하는 방법
# [ 원격의 새 브랜치 확인 방법 ]
# [1] 원격의 새로운 브랜치를 다운받지 않고, 확인만 해보고 싶은 경우
$git checkout origin/브랜치명
# [2] 원격의 새로운 브랜치를 다운받으며, 내 컴퓨터(로컬)에도 새로운 브랜치명을 똑같이 만들어, 받아오겠다.
$git switch -t origin/브랜치명
# 이는 로컬에도 해당 브랜치가 생겨나는 것이며, 앞으로 로컬의 이 브랜치는 원격의 해당 브랜치와 자동 연결하도록 한다.
* 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |