일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- es6
- Baekjoon
- Git
- django rest framework
- c++
- 백준
- Algorithm
- AWS
- API
- 파이썬 알고리즘
- 알고리즘 연습
- 파이썬
- web
- CSS
- django widget
- javascript
- 알고리즘 문제
- HTML
- DRF
- form
- django ORM
- js
- MAC
- 알고리즘
- java
- 알고리즘 풀이
- react
- 장고
- PYTHON
- Django
- Today
- Total
수학과의 좌충우돌 프로그래밍
05. git의 원리(2) commit, status의 원리 본문
안녕하세요 강민성입니다.
이번에는 git 중에서 commit과 status의 원리에 대해서 알아보도록 하겠습니다.
기본적인 디렉토리와 내용은 저번 시간과 지어지니 참고해주시면 감사하겠습니다.
git commit 의 원리를 알아보자
위에서 말했듯이 저번 시간에 하던 디렉토리에서 이어서 하도록 하겠습니다.
먼저 현재 어떤 상태인지 git status를 통해 살펴보겠습니다.
3개의 파일이 생성되어있고 각각 add 가 되어 commit이 될 준비가 되었습니다.
3개의 파일을 모두 commit 해보도록 하겠습니다.
commit 메세지는 1로 입력하였습니다.
그 후 gistory의 변화를 관찰해보겠습니다.
gistory가 뭔지 모르겠다면, 위의 링크에서 다시 보시길 바랍니다.
2개의 디렉토리만 바뀌었던 add와 달리 많은 디렉토리가 변경되었습니다.
먼저 objects 폴더부터 확인해보겠습니다.
commit 메세지 1 이 파일의 내용이 저장되었을 때와 같은 방식으로
객체로서 저장이 되었습니다.
내용을 좀 더 자세히 보면 tree, author , committer 를 확인 할 수 있습니다.
tree 는 우리가 commit한 파일들을 확인할 수 있고
author 와 committer 는 작성자와 commit한 사람의 정보를 확인할 수 있습니다.
다음으로는 test2.txt 파일의 내용을 수정하고 다시 commit 해보겠습니다.
이번에는 commit 메세지를 2로 하고 다시 objects를 확인해보겠습니다.
아까와는 다르게 parent가 추가되었습니다.
tree는 마찬가지로 commit된 파일들을 확인할 수 있고
새로 생긴 parent는 이전의 commit과 연결되어 있습니다.
따라서 첫번째 commit 에서는 이전 commit 이 없었으므로 parent가 존재할 필요가 없었습니다.
정리를 해보면 commit을 하게 되면 그 정보가 객체로서 objects 에 저장이 됩니다.
commit 메세지와 여러 정보들에 따라 이를 암호화 시켜 objects 안에 디렉토리와 파일을 생성하게 됩니다.
그 파일안에는 다음과 같은 정보들이 담깁니다.
1. commit 메세지
2. tree : commit 한 파일들의 파일명과 그 내용
3. parent : 앞선 commit에 대한 정보
4. 파일의 수정자와 commit 한 자에 대한 정보
objects 디렉토리에 생성되는 파일들은 어떤 파일들일까?
새로운 파일을 만들어서 add 했을 때도, 또한 commit 했을 때도 objects 디렉토리가 변했습니다.
각 상황에 따라서 어떤 파일이 생기는 것인지 짚고 넘어가도록 하겠습니다.
생성되는 파일은 3가지 종류 중 하나 입니다.
( 파일의 종류는 좌측 상단에 [ ] 안에서 확인 할 수 있습니다. )
1. 파일의 내용을 담고 있는 blob
2. 파일명과 파일내용에 해당되는 정보가 담기는 tree
3. 전체적인 걸 아우르는 정보를 담고 있는 commit
git status의 원리를 알아보자
다음으로는 status가 어떤 원리도 동작하는지 알아보겠습니다.
commit한 직후, 변경사항이 없을 때는 아래와 같이 commit할 게 없다는 걸 알려주고
test2.txt 파일을 수정한 후에 status 명령을 하면
다음과 같이 어떤 파일이 변경되었는지 정확히 캐치합니다.
또한 add 를 한 후에도 commit 할 준비가 되었다는 점을 정확히 캐치합니다.
먼저 add 한 직후 gistory를 살펴보겠습니다.
add 후 index 디렉토리에서 test2.txt 를 확인해보면 파일이 수정된 형태로 존재하지만
objects 디렉토리에 있는 test2.txt 는 아직 수정되기 전의 내용으로 존재합니다.
따라서 이럴 경우에는 add 는 되었지만 아직 commit은 되지 않았다고 판단합니다.
이제 commit을 하게 되면 index 디렉토리의 내용과
objects 의 내용이 같아집니다.
이 때 로컬에 있는 파일도 이와 같으면 수정사항이 없는 것으로,
로컬에 있는 파일은 이들과 다르면 수정은 되었지만 add하기 전으로 판단을 하게 됩니다.
즉 우리가 개념적으로 알고 있던 stage area 가 내부적으로는 index 라는 디렉토리로 역할을 하고 있었습니다.
정리해보자면,
우리가 작업하고 있는 공간은 working directory
stage area 에 해당되는 공간은 index 또는 cache 라고도 부르고,
마지막으로 commit을 하게 되면 repository에 올라가게 됩니다.
'git' 카테고리의 다른 글
07.git merge, 그 종류와 충돌 해결 (0) | 2019.02.09 |
---|---|
06. git branch 생성과 정보확인하기 (0) | 2019.02.07 |
04. git의 원리(1) gistory와 add의 원리 (0) | 2019.02.05 |
03.git 변경사항 확인 및 과거로 돌아가기 (0) | 2019.02.04 |
02. git 설치 및 버젼관리(저장소 만들기 add, commit) (6) | 2019.02.03 |