Git의 3가지 공간(+reset/restore) / Git(1)
2022. 2. 25. 19:51
- 인프런에서 얄코선생님의 git강의를 보면서내용을 정리
1. Git의 세가지 공간
- git의 작업 공간은 working directory , staging area, repository로 총 세가지가 있음
- add나 commit 혹은 resotre를 사용하여 작업 내용의 위치를 세공간 어디든 자유롭게 이동시킬 수 있음
- working directory
- 작업공간. 마지막 커밋 이후로, 변경점이 존재하는 파일들을 다루는 공간(커밋 이후로 변경점이 존재하지 않는 파일들은 애초에 다룰 필요가 없음. 그대로 그냥 다음 커밋에 링크로 전해주면 되니까)
- tracked파일과 untracked파일이 존재함
- tracked파일 : 커밋된적이 있어, 깃의 관리하에 있는 파일.
- untracked파일 : gitignore에 적혀있어 관리할필요가 없거나, 깃의 관리하에 있었던 적이 없는 파일
- tracked가 된다는 것은, git의 관리대상에 정식으로 등록된 다는 것을 의미함. 따라서 새로 추가되는 파일은 add해줌으로써 해당 파일이 tracked될 것을 명시해줘야 한다. (이 과정이 존재하는 덕택에, git이 모든 새파일을 무조건 다 관리하지 않을 수 있음)
- 'git add' 명령어로 stagint area로 이동
- git restore로 working directory에서의 작업을 삭제할 수 있음(직전 커밋 상태로 돌아감. 즉 작업내역 초기화)
#staging area로 이동
git add (파일명)
#working directory에서 삭제(직전에 커밋했을 때의 상태로 돌아감)
git restore (파일명)
#모든 파일을 working directory에서 삭제(모든 파일이 직전에 커밋했을 때의 상태로 돌아감)
git restore .
- staging area
- 커밋을 위한 준비단계 에어리어
- 'git commit' 명령어로 repository로 이동할 수 있음
- 'git restore --staged'를 사용해서 working directory로 이동할 수 있음(작업내용이 초기화 되진 않음. 다만 이번 커밋에서 빼는 것)
#reposiotry로 이동(commit)
git commit -m "메세지"
#staging area에 있는 파일들 중 하나를 working directory로 이동
git restore --staged (파일명)
#staging area에 있는 파일들을 모두 working directory로 이동
git restore --staged .
- repository
- .git directory라고도 불림
- 커밋된 상태
2. 파일의 삭제(rm)와 이름변경(mv)
- 그냥 파일을 삭제하면, 삭제한 내역은 working directory에 있음
- 근데 'git rm'명령어로 파일을 삭제하면 , 파일의 삭제 내역이 staging area에 있음(git status로 확인가능)
git rm (파일명)
- 파일명을 변경하면, git은 working directory에서 기존 파일명을 가진 파일이 삭제&새로운 파일명을 가진 파일이 생성되었다고 인식함. 그 후에 git add해주면 거기서 제대로(파일 이름이 변경되었다고) 인식함(git status로 확인가능)
- 'git mv'명령어를 사용해서 파일명을 변경하면, 파일명이 변경된 상태가 바로 staging area에 있음
git mv (기존파일명) (바꿀파일명)
3. reset의 세가지 옵션
- 옵션 다음에 아무것도 기록하지 않으면, 직전 커밋이 대상이 됨 ex)git reset --hard >> 직전 커밋으로 돌아감
- --hard
- 직전의 커밋상태로 돌림.
- 즉 내가 어떤 상황에 있건 파일들을 직전에 커밋된 상태로 초기화시킴 >> 작업내역날아감
- --mixed
- 디폴트(따로 안적어주면 디폴트가 실행됨).
- 직전의 커밋을 취소하고, 직전의 커밋 내용을 repository에서 working directory로 이동(직전 커밋이후의 변경내용이 git add가 되어 있지 않은 상태)
- --soft
- 직전의 커밋을 취소하고, 직전의 커밋 내용을 repository에서 staging area로 이동(직전 커밋 이후의 변경내용이 git add가 되어 있는 상태)
- 추가)대상으로 입력한 커밋시점으로 딱 돌아가는(reset) 거임
- 커밋1 > 커밋2 > 커밋3 > 커밋4 을 한 상황에서, 커밋2의 해쉬태그를 입력하고 reset을 하면 커밋2가 딱 완료된 상황으로 돌아가는 것임
- 옵션을 hard를 햇다면, 커밋2가 완료된 시점 이후의 모든 내용이 사라짐
- 옵션을 mixed를 햇다면, 커밋2가 완료된 시점 이후의 모든 커밋이 사라지고, 작업한 모든 내용이 working directory에 남아있음(즉, 작업 내용은 사라지지 않고, staging도 되어 있지 않음)
- 옵션을 soft로 햇다면, 커밋2가 완료된 시점 이후의 모든 내용이 스테이징되어 있는 상태가 됨
- 그러면 만약에, 커밋4이후에 staging하지 않은 내용(즉 저장만 하고 add는 하지 않은 내용)이 있을 떄 soft reset을 하면 어떻게 될까?
- 이 부분에 대해서 테스트를 해봣는데, 헝크별로 다르게 나옴.
- 즉 커밋2 이후 커밋4까지의 작업은 staing된걸로, 커밋 4이후 저장은 햇으나 staging하지 않은 부분은 그대로 staging하지 않은 걸로 나옴
4. restore을 활용하여, 파일을 특정 커밋상태로 되돌리기
- restore을 활용해, 특정파일만 특정 커밋상태로 되돌릴 수 있음
- 특정 커밋상태로 돌아간 파일은 , 그냥 직전 커밋에서 파일이 변경된 상태가 됨
- ex)A파일을 35파일에서 31파일로 restore로 돌리면, A파일은 31커밋이 완료된 시점의 내용을 가지고 저장됨
- 깃입장에서는 그냥 A파일이 35커밋내용에서 31커밋내용으로 바뀜+저장된거니까, 그냥 있는 그대로 인식해서 그 내역을 working directory에 집어 넣음
#파일을 특정 커밋상태로 되돌리기
git restore --source=(커밋 해시) (파일명)
#헤드를 사용가능
git restore --source=(헤드) (파일명)
git restore --source=HEAD^^^^ (파일명)
'개발도구 > git' 카테고리의 다른 글
노션 이동 완료Git : GitHub // Git(5) (0) | 2022.02.25 |
---|---|
Git : Branch // Git(4) (0) | 2022.02.25 |
Git commit // Git(3) / 노션이동완료 (0) | 2022.02.25 |
과거로 돌아가는 방법 (reset , revert) // Git(2) / 노션이동완료 (0) | 2022.02.25 |
Git 기초 +기타내용 // git(0) (0) | 2022.02.25 |