status의 원리

• index라는 파일, status의 명령이 어떻게 동작하는지에 대한 공부(직관적인 이해)

• index 파일과 최신 커밋 파일(tree)의 비교를 통해 git status가 커밋할 파일이 있는지, 없는지를 결정
  • 두 내용이 일치하면 git status에서 커밋할 내용이 없다고 판단
• vim f2.txt로 내용을 변경 후, git status로 확인해보면 f2.txt 파일이 수정 된 것을 확인 할 수 있음
  • git은 index 파일에 적혀있는 f2.txt의 내용의 값과 실제 f2.txt의 내용이 다르다면, 해당 파일이 수정 되었다고 감지
• git add f2.txt를 하고, git status로 확인하면, 수정 된 것은 똑같으나 changes to be committed를 확인 가능
  • 즉, 커밋 대상에 포함 된 상태가 됨
  • 두 개의 상태를 gistory로 확인해보면, object에 새로운 파일이 추가된 것을 확인 가능(커밋 대기 상태)
• 이를 통해 git은 index의 내용과 최신 커밋의 tree가 가르키고 있는 f2.txt의 내용이 다르다면, 현재 f2.txt는 index에 add되어 커밋 대기 상태가 된 것을 알 수 있음
• git commit을 하고 커밋 메세지를 작성 후 gistory를 확인하면, 커밋이 만들어졋고 그 tree에는 f2.txt의 고유번호가 index과 tree가 같게 된 것을 확인 가능
  • index와 저장소와 프로젝트 폴더 세가지가 정확하게 일치하기 때문에 git status로는 더이상 커밋할게 없다고 알려주게 됨
• index 파일과 commit의 tree 사이의 관계를 정리해보면?

• workspace는 우리가 .git 디렉터리 바깥의 프로젝트 폴더를 의미
• workspace에서 git add를 하게 되면 해당 내용들이 index파일에 등록되고, 커밋을 하면 index에 등록된 내용들이 local repository에 저장됨
  • object가 저장 되며, commit object, tree, 파일이 저장 됨

• staging area는 위의 그림에서 index파일, 즉 커밋 대기 상태인 staging area에 올라간 상태를 의미

• woriking directory에서 git add를 하게 되면 saging area, git commit 하면 repository에 저장 됨

• git의 구조
  • workspace = working directory = work tree
  • index = staging area = cache
  • repository