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^^^^ (파일명)

 

BELATED ARTICLES

more