티스토리 뷰
Git 파일의 라이프 사이클
Git을 사용하고 있다면, 파일을 수정하다가 현재까지 작업한 내용을 저장하고 싶을 때 스냅샷을 커밋하면 된다(여기서 수정은 파일의 생성과 삭제를 모두 포함). 이를 위해 워킹 디렉토리(Working Directory or Tree)에서 작업한 파일들을 Staging Area에 올려 스냅샷에 포함시켜야 한다. 방법은 간단하다.
스냅샷(Snapshot) : Staging Area에 올라간 파일들의 최상위 디렉토리(트리) - 이전 글 참고
워킹 디렉토리의 모든 파일은 크게 Tracked(관리대상)와 Untracked(관리대상이 아님)로 나눈다. Tracked 파일은 이미 스냅샷에 포함돼 있던 파일이다.
Tracked 파일은 또 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 상태 중 하나다. 간단히 말하자면 Git이 알고 있는 파일이라는 것이다.
Tracked 파일 : 스냅샷에 포함돼 있는 파일. 즉, Staging Area에 올라가 Git에 의해 관리되고 있는 파일
그리고 나머지 파일은 모두 Untracked 파일이다. Untracked 파일은 워킹 디렉토리에 있는 파일 중 스냅샷에도 Staging Area에도 포함되지 않은 파일이다. 처음 저장소를 Clone 하면 모든 파일은 Tracked이면서 Unmodified 상태다.
마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서 어떤 파일을 수정하면 Git은 그 파일을 Modified 상태로 인식한다. 실제로 커밋을 하기 위해서는 이 수정한 파일을 Staged 상태로 만들고, Staged 상태의 파일을 커밋한다. 이런 라이프사이클을 계속 반복한다.
간단한 예시로 위 파일의 라이프 사이클을 따라가 보겠다.
Untracked
➜ git-study git:(master) git status
현재 브랜치 master
커밋할 사항 없음, 작업 폴더 깨끗함
➜ git-study git:(master) vim test.txt
➜ git-study git:(master) ✗ mkdir commit-directory
➜ git-study git:(master) ✗ vim commit-directory/test2.txt
➜ git-study git:(master) ✗ git status
현재 브랜치 master
추적하지 않는 파일:
(커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
test.txt
commit-directory/
커밋할 사항을 추가하지 않았지만 추적하지 않는 파일이 있습니다 (추적하려면 "git
add"를 사용하십시오)
워킹 디렉토리가 깨끗한 상태에서 총 2개의 파일을 생성했다. 그 중 하나는 디렉토리를 하나 추가한 뒤 그 안에 생성했다.
- test.txt
- commit-directory/test2.txt
그 다음 현재 상태를 확인해 보면, 새로 생성한 파일들이 아직 추적되지 않은 상태라고 알려준다(track이 추적하다라고 번역됨). 다만 Git에서는 디렉토리도 tree
라는 객체로 다루고, 이 tree
안에 추가한 파일 객체(정확히는 객체의 링크 주소)가 포함되는 형태이기 때문에 추가한 디렉토리를 그대로 표시해 준다. 이 상태에서 test.txt 파일만 Staging Area에 올려 Staged 상태로 만들어 보겠다.
git status : Staging Area와 워킹 디렉토리를 비교해 달라진 부분을 표시해 주는 명령어
Staged
➜ git-study git:(master) ✗ git add test.txt
➜ git-study git:(master) ✗ git status
현재 브랜치 master
커밋할 변경 사항:
(use "git restore --staged <file>..." to unstage)
새 파일: test.txt
추적하지 않는 파일:
(커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
commit-directory/
커밋할 변경 사항에 test.txt가 추가됐다. 따라서 현재 워킹 디렉토리의 상황은 이렇다.
- test.txt : Staging Area에 올라간 상태 == Tracked 파일 == Git에 의해 관리되고 있는 파일 == Staged
- commit-directory/test2.txt : Untracked 파일
Unmodified (commit)
➜ git-study git:(master) ✗ git commit -m "커밋 테스트를 위한 커밋-1"
[master 8d21d31] 커밋 테스트를 위한 커밋-1
1 file changed, 2 insertions(+)
create mode 100644 test.txt
➜ git-study git:(master) ✗ git log
commit 8d21d31ec45206cc2fa021ec7bbc943fad9632fc (HEAD -> master)
Author: on1ystar <tjdwls0607@naver.com>
Date: Thu Oct 24 17:39:31 2024 +0900
커밋 테스트를 위한 커밋-1
git commit
명령어를 사용해 Staging Area에 있는 파일들을 커밋했다. 이 순간 새로운 commit
객체가 생성되고, 그 안에 test.txt 파일이 포함되어 있는 스냅샷 링크 주소가 포함될 것이다. 이 전 포스팅에서 한 번 해봤듯이 생성된 commit
의 링크 주소인 sha-1을 조회해 볼 수 있다. 그리고 그 안에 있는 tree
객체의 링크 주소까지 조회해 보겠다.
➜ git-study git:(master) ✗ git cat-file -p 8d21d31ec45206cc2fa021ec7bbc943fad9632fc
tree 9ae300a719831c469963aae88287347c75103047
author on1ystar <tjdwls0607@naver.com> 1729759171 +0900
committer on1ystar <tjdwls0607@naver.com> 1729759171 +0900
커밋 테스트를 위한 커밋-1
➜ git-study git:(master) ✗ git cat-file -p 9ae300a719831c469963aae88287347c75103047
100644 blob dd4c20b86bdac91798f87657a48e2f83af4fea82 test.txt
새로 생성된 commit
객체에 포함된 tree
객체의 링크 주소 및 메타 데이터들을 확인할 수 있고, tree
객체 안에는 예상대로 test.txt 파일의 링크 주소(Git에서는 blob
객체)가 포함되어 있다. (이에 대한 자세한 내용은 이전 포스팅 참고)
➜ git-study git:(master) ✗ git status
현재 브랜치 master
추적하지 않는 파일:
(커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
commit-directory/
커밋할 사항을 추가하지 않았지만 추적하지 않는 파일이 있습니다 (추적하려면 "git
add"를 사용하십시오)
git status
로는 이제 test.txt 파일이 보이지 않는다. Unmodified 상태의 파일들은 표시하지 않기 때문이다. 마지막으로 test.txt 파일을 살짝 수정해 보겠다.
Modified
➜ git-study git:(master) ✗ vim test.txt
➜ git-study git:(master) ✗ git status
현재 브랜치 master
커밋하도록 정하지 않은 변경 사항:
(무엇을 커밋할지 바꾸려면 "git add <파일>..."을 사용하십시오)
(use "git restore <file>..." to discard changes in working directory)
수정함: test.txt
추적하지 않는 파일:
(커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
commit-directory/
커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)
test.txt 파일이 수정함으로 표시되는데 이 상태가 modified 상태다. Git이 이전 commit과 비교했더니 달라진 부분이 생겼기 때문이다.
그러면 만약에 Git이 이 파일을 다시 관리하지 않도록 하는(Staging Area에 내리는) 방법이 있을까? 물론 있다. 또한 commit을 되돌리는 방법도 있다. Git은 모든 파일들을 스냅샷의 스트림으로 관리하는 방식이기 때문에 사용자가 원하면 어떤 순간이든 돌아갈 수 있다. 그것도 매우 빠르고 쉽게 가능해 Git의 큰 장점 중 하나다. 물론, 어디까지나 Git이 관리하고 있는 파일들이며, 스냅샷에 포함된 적이 있어야 한다.
파일의 상태 되돌리기
파일의 상태들을 되돌리기 전에 알아야 할 것이 있다. Git에서는 이전 상태도 되돌리는 것은 쉽다. 하지만 되돌린 것을 다시 복구하기는 쉽지 않다. 특히나 커밋되지 않은 경우에는 복구할 방법이 없다. 때문에 되돌리기를 위한 명령어들은 더 자세히 알 필요가 있다.
restore : Modified 파일 되돌리기(수정사항 되돌리기)
이전에 Modified 예시를 보면, Git에서 친절하게 아래 메세지를 출력해 준다.
use "git restore <file>..." to discard changes in working directory
워킹 디렉토리의 변경 사항을 버리러면 git restore
명령어를 사용하라고 한다. 한 번 해보자.
➜ git-study git:(master) ✗ git restore test.txt
➜ git-study git:(master) ✗ git status
현재 브랜치 master
추적하지 않는 파일:
(커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
commit-directory/
커밋할 사항을 추가하지 않았지만 추적하지 않는 파일이 있습니다 (추적하려면 "git
add"를 사용하십시오)
test.txt 파일이 사라졌다. 실제로 파일 내용을 확인해 보면, 수정한 부분이 모두 사라진 것을 확인할 수 있다. 이는 Git이 관리하고 있는 파일이면서, 이전에 Commit된 적이 있는 Modified 상태여서 가능한 것이다.
Git이 이전 커밋의 스냅샷에서 test.txt 파일의 최신 상태를 가져과 간단하게 덮어씌우는 것이다. 때문에 아쉽게도 수정한 내용을 다시 되돌릴 수는 없다.
💡 혹여나 restore 명령어가 먹히지 않는다면 Git 버전이 2.23 이전인지 확인해 봐야 한다. 이전 버전에서는 checkout 명령어가 이를 대체했다. 하지만 checkout 명령어의 역할이 너무 많아 restore, switch 명령어로 역할을 나눠 적재적소에 사용하도록 개선했다. - Highlights from Git 2.23
restore --staged : 파일 상태를 Unstage로 변경하기
다음은 Staging Area와 워킹 디렉토리 사이를 넘나드는 방법이다. 새로운 파일을 생성한 뒤, Staging Area에 추가해 보자.
➜ git-study git:(master) vim test3.txt
➜ git-study git:(master) ✗ git add .
➜ git-study git:(master) ✗ git status
현재 브랜치 master
커밋할 변경 사항:
(use "git restore --staged <file>..." to unstage)
새 파일: test3.txt
이전에 사용했던 restore
명령어에 --statged
옵션만 추가해 주면 된다.
➜ git-study git:(master) ✗ git restore --staged test3.txt
➜ git-study git:(master) ✗ git status
현재 브랜치 master
추적하지 않는 파일:
(커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
test3.txt
커밋할 사항을 추가하지 않았지만 추적하지 않는 파일이 있습니다 (추적하려면 "git
add"를 사용하십시오)
💡 참고로 원래는 reset 명령어를 사용해야만 했다. 하지만 위험 부담이 크기 때문에 2.23 버전부터 추가된 restore 명령어를 사용하라고 Git에서 추천하고 있다.
commit --amend : 최신 커밋 간단 수정
이전의 커밋을 완전히 새로 고쳐서 새 커밋으로 변경하는 것을 의미한다. 이전의 커밋은 일어나지 않은 일이 되는 것이고 당연히 히스토리에도 남지 않는다. 만약 마지막으로 커밋하고 나서 수정한 것이 없다면(커밋하자마자 바로 이 명령을 실행하는 경우) 조금 전에 한 커밋과 모든 것이 같다.
우리가 아직 Staging Area에 추가하지 않은 파일이 있었다. 이 파일을 이전 커밋에 추가해 보자.
➜ git-study git:(master) ✗ git add commit-directory/
➜ git-study git:(master) ✗ git commit --amend -m "commit --amend 테스트를 위한 커밋"
[master ed84b90] commit --amend 테스트를 위한 커밋
Date: Thu Oct 24 17:39:31 2024 +0900
2 files changed, 3 insertions(+)
create mode 100644 commit-directory/test2.txt
create mode 100644 test.txt
➜ git-study git:(master) git status
현재 브랜치 master
커밋할 사항 없음, 작업 폴더 깨끗함
워킹 디렉토리가 깨끗해 졌다(이전 예시에서 새로 생성한 test3.txt 파일은 삭제함). 커밋 로그를 보면 commit-directory/test2.txt 파일이 추가된 것을 확인할 수 있다. 그런데 이전 커밋에 추가했던 test.txt 파일도 새로 추가된 것처럼 보인다. 그럼 이전 커밋은 어떻게 됐을까? 직접 다 확인해 보자.
➜ git-study git:(master) git log
commit e8abaeb47ecf55eb8693ae7fd35b5a906d40a378 (HEAD -> master)
Author: on1ystar <tjdwls0607@naver.com>
Date: Thu Oct 24 17:39:31 2024 +0900
commit --amend 테스트를 위한 커밋
가장 먼저 보이는 차이점은 이전 커밋이 사라지고 새로운 커밋이 만들어 졌다는 것이다. --amend
옵션은 이전 커밋 정보에 새로운 커밋 정보를 덮어씌우는 옵션이다.
이전 예시에서 이전 커밋 로그를 가져와 비교해 보자.
➜ git-study git:(master) ✗ git log
commit 8d21d31ec45206cc2fa021ec7bbc943fad9632fc (HEAD -> master)
Author: on1ystar <tjdwls0607@naver.com>
Date: Thu Oct 24 17:39:31 2024 +0900
커밋 테스트를 위한 커밋-1
git log
에서 확인할 수 있는 차이점은 커밋 객체의 sha-1 체크섬(링크 주소) 값과 새로 작성한 커밋 메세지다. 즉, 완전 새로운 커밋 객체가 생성됐다는 것이다. Date
값을 보면 같은 것을 확인할 수 있는데, 이는 이전 커밋의 메타 데이터 값을 그대로 사용하기 때문이다. 만약 커밋 메세지를 새로 작성하지 않았다면 이 역시 같았을 것이다.
➜ git-study git:(master) git cat-file -p e8abaeb47ecf55eb8693ae7fd35b5a906d40a378
tree 2961b358eca986a3e92a437d56e114a22cd5851d
author on1ystar <tjdwls0607@naver.com> 1729759171 +0900
committer on1ystar <tjdwls0607@naver.com> 1729764440 +0900
commit --amend 테스트를 위한 커밋
➜ git-study git:(master) git cat-file -p 2961b358eca986a3e92a437d56e114a22cd5851d
040000 tree a8c6a1e96f754658ae9115d56dce510cd55e1a4a commit-directory
100644 blob dd4c20b86bdac91798f87657a48e2f83af4fea82 test.txt
실제 체크섬을 확인해 보면, test.txt 파일의 blob
체크섬 값은 같지만 tree
의 값은 바뀐 것을 확인할 수 있다.
- 이전 커밋의
tree
체크섬 : 9ae300a719831c469963aae88287347c75103047 - 이전 커밋의 test.txt
blob
체크섬 : dd4c20b86bdac91798f87657a48e2f83af4fea82
tree
체크섬 값이 바뀐 이유는, 새로운 파일이 스냅샷에 추가됐기 때문에 이를 포함하는 최상위 tree
객체를 생성한 것이다. 그 외의 값들은 덮어씌운다는 의미 그대로 이전 커밋에서 생성한 정보를 그대로 사용한다.
이 명령어를 사용하는 경우는 깜빡한 아주 간단한 작업들을 이전 커밋에 추가하고 싶을 때 유용하게 사용할 수 있다. 쓸데없이 새로운 커밋을 새로 생성하지 않아도 되기 때문이다.
Reset 명확히 알고 가기
세 개의 트리
여기서 “트리” 란 실제로는 “파일의 묶음” 이다. 자료구조의 트리가 아니다 세 트리 중 Index는 트리도 아니지만, 이해를 쉽게 하려고 일단 트리라고 한다.
Git은 일반적으로 세 가지 트리를 관리하는 시스템이다.
HEAD | 현재 브랜치를 가리키는 포인터, 마지막 커밋 스냅샷, 다음 커밋의 부모 |
Index | Staging Area, 다음에 커밋할 스냅샷 |
워킹 디렉토리(working directory) | 실제 파일이 존재하는 공간 |
예로 들어 file.txt
파일 하나를 수정하고 커밋한다. 이것을 세 번 반복한다. 그러면 히스토리는 아래와 같이 된다.
reset
명령은 이 세 트리를 간단하고 예측 가능한 방법으로 조작한다. 트리를 조작하는 동작은 세 단계로 이루어진다.
1 단계: HEAD 이동
reset
명령이 하는 첫 번째 일은 HEAD 브랜치를 이동시킨다. HEAD는 계속 현재 브랜치를 가리키고 있고, 현재 브랜치가 가리키는 커밋을 바꾼다. HEAD가 master
브랜치를 가리키고 있다면(즉 master
브랜치를 Checkout 하고 작업하고 있다면) git reset 9e5e6a4
명령은 master
브랜치가 9e5e6a4
를 가리키게 한다.
reset
명령에 커밋을 넘기고 실행하면 언제나 이런 작업을 수행한다. reset --soft
옵션을 사용하면 딱 여기까지 진행하고 동작을 멈춘다.
reset
명령은 가장 최근의 git commit
명령을 되돌린다. git commit
명령을 실행하면 Git은 새로운 커밋을 생성하고 HEAD가 가리키는 브랜치가 새로운 커밋을 가리키도록 업데이트한다. reset
명령 뒤에 HEAD~
(HEAD의 부모 커밋)를 주면 Index나 워킹 디렉토리는 그대로 놔두고 브랜치가 가리키는 커밋만 이전으로 되돌린다. git commit
명령을 실행하면 git commit --amend
명령의 결과와 같아진다.
2 단계: Index 업데이트 (--mixed)
여기서 git status
명령을 실행하면 Index와 reset
명령으로 이동시킨 HEAD의 다른 점이 녹색으로 출력된다.
reset
명령은 여기서 한 발짝 더 나아가 Index를 현재 HEAD가 가리키는 스냅샷으로 업데이트할 수 있다.
--mixed
옵션을 주고 실행하면 reset
명령은 여기까지 하고 멈춘다. reset
명령을 실행할 때 아무 옵션도 주지 않으면 기본적으로 --mixed
옵션으로 동작한다(예제와 같이 git reset HEAD~
처럼 명령을 실행하는 경우).
위의 다이어그램을 보고 어떤 일이 일어날지 한 번 더 생각해보자. 가리키는 대상을 가장 최근의 커밋으로 되돌리는 것은 같다. 그러고 나서 Staging Area 를 비우기까지 한다. git commit
명령도 되돌리고 git add
명령까지 되돌리는 것이다.
3 단계: 워킹 디렉토리 업데이트 (--hard)
reset
명령은 세 번째로 워킹 디렉토리까지 업데이트한다. --hard
옵션을 사용하면 reset
명령은 이 단계까지 수행한다.
이 과정은 어떻게 동작하는지 가늠해보자. reset
명령을 통해 git add
와 git commit
명령으로 생성한 마지막 커밋을 되돌린다. 그리고 워킹 디렉토리의 내용까지도 되돌린다.
이 --hard
옵션은 매우 매우 중요하다. reset
명령을 위험하게 만드는 유일한 옵션이다. Git에는 데이터를 실제로 삭제하는 방법이 별로 없다. reset
명령을 어떻게 사용하더라도 간단히 결과를 되돌릴 수 있다. 하지만 --hard
옵션은 되돌리는 것이 불가능하다. 이 옵션을 사용하면 워킹 디렉토리의 파일까지 강제로 덮어쓴다. 이 예제는 파일의 v3버전을 아직 Git이 커밋으로 보관하고 있기 때문에 reflog
를 이용해서 다시 복원할 수 있다. 만약 커밋한 적이 없다면 Git이 덮어쓴 데이터는 복원할 수 없다.
References
'Git 공부' 카테고리의 다른 글
Git의 원리를 이해하고 사용하기 - 3 (브랜치, 병합, 리모트 브랜치) (7) | 2024.11.01 |
---|---|
Git의 원리를 이해하고 시작하기 - 1 (Git의 핵심, 데이터 모델) (1) | 2024.10.22 |
Git Github 사용법 (0) | 2019.03.18 |
Git fatal: refusing to merge unrelated histories (0) | 2019.03.15 |
Git 병합 충돌 (0) | 2019.03.11 |
- Total
- Today
- Yesterday
- jsp
- 스프링 테스트
- Spring Boot
- 방명록 프로젝트
- 운영체제 반효경
- 파이썬 for Beginner 연습문제
- 김영환
- Gradle
- Python Cookbook
- git branch
- 쉽게 배우는 운영체제
- Computer_Networking_A_Top-Down_Approach
- Spring Data JPA
- shell code
- spring mvc
- 생활코딩 javascript
- 쉘 코드
- 선형 회귀
- Do it! 정직하게 코딩하며 배우는 딥러닝 입문
- 프로그래머스
- git merge
- Spring
- 패킷 스위칭
- 파이썬 for Beginner 솔루션
- 지옥에서 온 git
- 스프링
- JPA
- git
- Thymeleaf
- 스프링 컨테이너
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |