commit
commit은 Staging Area의 파일을 Repository로 옮기는 명령어이다.
위의 사진을 보면 git status를 입력하였을 때 새로 추가된 파일 f1~3.txt 가 3개 존재하는데 현재 이 파일들은 Staging Area의 존재하는 상태이다. 이것을 git Commit를 통하여 Repository로 올려주었다. 그럼 이 때의 gistory로 내부상태를 알아보자
commit의 동작 원리
gistory를 이용하여 이 명령어 실행 후 파일의 최근 조작이 가해진것들을 확인하면 아래의 사진과 같다.
여기서 Objects 를 하나 클릭하여 내용을 확인해보니 내가 방금 commit으로 버전을 올린것이 아래의 사진 처럼 해당 파일내에 존재하게된다. 이는 사전에 알아봤던 add와 같이 Objects에 해당 버전의 내용이 들어간다는 것을 알 수 있는 부분이다.
이러하기에 commit도 사실 object 객체라고 말할 수 있다.
위의 tree 후 적힌 문자열은 저 버전에 들어간 파일들의 이름과 내용 등이 링크가 되어있다.
만약, 기존에 commit 된 파일을 수정 후 재 commit한다면?
기존에 업로드 된 f2.txt의 파일 내용을 수정 후 재 커밋을 하였다. 아래의 사진은 그 과정이다.
이렇게 다시 commit을 한 후 이를 gistory에서 보게되면 기존대로 5가지 정도의 파일이 갱신되는데 이 때 objects 파일을 들어가면 parent라는 파일이 생긴 것을 알 수 있고 클릭할 수 있는 링크가 활성화되어있을 것이다. 이것을 누르면 아래의 사진 처럼 나온다.
아래의 [commit] 내용은 전 commit 했을 때 f2.txt의 내용이다.
이 때 현재 commit 의 tree 값과 이전 commit의 tree값이 다른것을 볼 수 있다.
여기서 각각의 트리를 들어가서 이전의 파일에 내용을 파악할 수 있다. 물론 현재의 것 또한 파악이 가능하다.
이런식으로 스냅샷 기능이 존재한다.
이를 Tree라는 구조로 각각의 버전이 이를 보유함.
새로운 디렉토리에 기존에 있던것을 복사한다면?
위에는 새 디렉토리와 복사를 위한 명령어들이다. 이 작업 이후 gistory를 보면 아래처럼 바뀐다.
두 가지가 수정되어서 저장이 되는데 이 때, Object 주소는 새로 생긴것이 아니고 f1.txt의 내용과 공유 됨으로 index를 보면 오리지널 f1.txt와 카피 f1.txt의 주소가 같다는 것을 알 수 있다. 그 후 해당 버전을 commit 해주면 gistory에 최근 갱신된 파일은 이렇게 존재한다.
여기서 objects를 들어가 보면 앞서 했던것처럼 링크를 타고타고해서 해당 파일의 내용및 위치 그리고 전버전의 대한 것들 또한 볼 수 있다.
Objects에는 무엇이 담겨있는가?
- file의 내용을 담고있는 blob
- 어떤 Directory에 파일명과 해당 파일내용에 대한 정보를 담고 있는 tree
- commit의 오븍젝트 ID
