소개
이 랩에서는 Git 커밋이 수정되었는지 여부를 확인하는 방법을 배우게 됩니다. git reflog 명령을 사용하여 참조 업데이트의 기록을 보고 수정 작업을 파악할 수 있습니다.
또한 git log를 사용하여 커밋을 비교하고 수정된 커밋과 수정되지 않은 커밋의 차이점을 이해하여, 저장소의 기록을 검토하는 실질적인 기술을 습득하게 됩니다.
git reflog 에서 Amend 항목 확인
이 단계에서는 git reflog 명령을 살펴보고, 커밋 수정과 같은 작업을 포함하여 저장소의 기록을 확인하는 방법을 배우겠습니다.
먼저, 프로젝트 디렉토리에 있는지 확인해 보겠습니다. 터미널을 열고 my-time-machine 디렉토리로 이동합니다.
cd ~/project/my-time-machine이제 git reflog 명령을 사용하여 저장소의 기록을 확인해 보겠습니다. reflog (참조 로그) 는 저장소의 브랜치 팁 및 기타 참조에 대한 업데이트를 기록합니다. 이는 커밋 기록을 보여주는 git log와는 다릅니다.
다음 명령을 입력합니다.
git reflog다음과 유사한 출력을 볼 수 있습니다.
a1b2c3d (HEAD -> master) HEAD@{0}: commit: Send a message to the future
a1b2c3d (HEAD -> master) HEAD@{1}: initial commit (amend): Send a message to the future
e4f5g6h HEAD@{2}: commit (initial): Send a message to the future이 출력을 자세히 살펴보겠습니다.
- 각 줄은
HEAD와 같은 참조를 업데이트한 작업을 나타냅니다. HEAD@{0}은 가장 최근 작업이고,HEAD@{1}은 그 이전 작업이며, 그 외에도 마찬가지입니다.- 각 줄의 첫 번째 부분 (
a1b2c3d,e4f5g6h) 은 커밋 해시입니다. "amend" 작업 후 커밋 해시가 어떻게 변경되는지 확인하십시오. - 커밋 해시 뒤의 텍스트는
commit,initial commit (amend)또는commit (initial)과 같은 작업을 설명합니다.
git reflog는 손실된 커밋을 복구하거나 저장소의 현재 상태로 이어진 작업 시퀀스를 이해하는 강력한 도구입니다. HEAD가 있었던 위치를 보여주며, 해당 커밋이 더 이상 브랜치 기록의 일부가 아닌 경우에도 (예: amend 또는 rebase 후).
예제 출력에서 initial commit (amend)와 같은 항목을 볼 수 있습니다. 이는 초기 커밋이 수정되었음을 나타냅니다. 커밋을 수정하면 마지막 커밋이 스테이징된 변경 사항을 포함하는 새 커밋으로 대체됩니다. git log는 최종 수정된 커밋만 표시하지만, git reflog는 원래 초기 커밋과 수정된 커밋을 모두 표시합니다.
git reflog를 이해하는 것은 특히 git commit --amend와 같이 기록을 다시 쓰는 명령을 사용할 때 프로젝트의 기록을 탐색하는 데 중요합니다.
git log 를 사용하여 커밋 비교
이 단계에서는 git log 명령을 사용하여 커밋 기록을 보고, 특히 git commit --amend를 사용한 후 git reflog와 어떻게 다른지 이해해 보겠습니다.
여전히 ~/project/my-time-machine 디렉토리에 있는지 확인하십시오.
이제 git log를 사용하여 커밋 기록을 확인해 보겠습니다.
git log --oneline--oneline 옵션은 커밋 기록을 간결하게 보여주며, 각 커밋을 한 줄에 표시합니다.
다음과 유사한 출력을 볼 수 있습니다.
a1b2c3d (HEAD -> master) Send a message to the future이 출력을 이전 단계의 git reflog 출력과 비교해 보십시오. git log는 최종 수정된 커밋 하나만 표시합니다. amend 작업으로 대체된 원래 초기 커밋은 표시하지 않습니다.
이것이 git log와 git reflog의 주요 차이점입니다. git log는 현재 브랜치 팁에서 도달할 수 있는 커밋의 기록을 보여주는 반면, git reflog는 HEAD 및 기타 참조가 가리켰던 기록을 보여줍니다.
git log를 프로젝트의 공식 게시된 기록으로, git reflog를 저장소에서 수행한 모든 작업의 개인 일기로 생각할 수 있습니다.
또한 git log를 사용하여 서로 다른 커밋을 비교할 수 있습니다. 현재 기록에는 하나의 커밋만 있지만, 여러 커밋이 있는 실제 프로젝트에서는 git log commit1..commit2와 같은 명령을 사용하여 기록의 두 특정 지점 사이의 커밋을 보거나, git diff commit1 commit2를 사용하여 두 커밋 사이에 도입된 정확한 변경 사항을 볼 수 있습니다.
지금은 git log가 커밋 기록을 표시하고 git reflog가 참조 업데이트 기록을 표시한다는 것을 이해하는 것이 중요합니다.
수정되지 않은 커밋 테스트
이 단계에서는 --amend 플래그를 사용하지 않고 새 커밋을 생성하고 git log와 git reflog 모두에서 어떻게 나타나는지 관찰합니다. 이를 통해 이러한 명령이 기록을 다르게 추적하는 방식을 더욱 확실하게 이해할 수 있습니다.
먼저, message.txt 파일에 내용을 더 추가해 보겠습니다. 새 줄을 추가합니다.
echo "Hello again, Future Me!" >> message.txt>> 연산자는 텍스트를 덮어쓰는 대신 기존 파일에 추가합니다.
이제 상태를 확인하여 변경 사항을 확인해 보겠습니다.
git statusmessage.txt가 수정되었음을 나타내는 출력을 볼 수 있습니다.
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: message.txt
no changes added to commit (use "git add" and/or "git commit -a")다음으로, 변경 사항을 스테이징해야 합니다.
git add message.txt이제 이전 커밋을 수정하지 않고 새 커밋을 생성해 보겠습니다.
git commit -m "Add another message"새 커밋을 확인하는 출력을 볼 수 있습니다.
[master 1a2b3c4] Add another message
1 file changed, 1 insertion(+)이제 git log를 다시 확인해 보겠습니다.
git log --oneline이번에는 두 개의 커밋을 볼 수 있습니다.
1a2b3c4 (HEAD -> master) Add another message
a1b2c3d Send a message to the future두 커밋 모두 git log에 표시됩니다. 두 번째 커밋이 첫 번째 커밋 위에 추가되어 브랜치의 기록을 확장했기 때문입니다.
마지막으로, git reflog를 확인해 보겠습니다.
git reflog다음과 유사한 출력을 볼 수 있습니다.
1a2b3c4 (HEAD -> master) HEAD@{0}: commit: Add another message
1a2b3c4 (HEAD -> master) HEAD@{1}: commit (amend): Send a message to the future
e4f5g6h HEAD@{2}: commit (initial): Send a message to the futuregit reflog는 모든 작업을 표시합니다. 초기 커밋, 수정된 초기 커밋, 그리고 방금 생성한 새 커밋입니다. HEAD를 이동시킨 각 작업이 기록됩니다.
이 단계에서는 --amend 없이 새 커밋을 생성하면 git log와 git reflog 모두 새 커밋을 표시하지만, git reflog는 git log가 표시하지 않는 수정된 커밋의 기록을 계속 유지한다는 것을 보여줍니다.
요약
이 Lab 에서는 Git 커밋이 수정되었는지 확인하는 방법을 배웠습니다. HEAD와 같은 참조에 대한 업데이트 기록을 제공하여 커밋 수정과 같은 작업을 볼 수 있게 해주는 git reflog 명령을 살펴보았습니다. reflog 출력을 검토하여 수정 작업을 나타내는 항목을 식별하고 이러한 작업 후 커밋 해시가 어떻게 변경되는지 관찰할 수 있습니다.
또한 git reflog는 git log를 통해 더 이상 직접 액세스할 수 없는 커밋에 대해서도 저장소의 작업 순서를 이해하는 데 유용한 도구임을 배웠습니다. 이는 손실된 작업을 복구하거나 저장소 기록 문제를 진단하는 데 도움이 됩니다.
