이 랩에서는 Git 커밋이 병합 커밋인지 확인하는 방법을 배우게 됩니다. git show 명령을 사용하여 커밋 세부 정보를 검사하고, 특히 병합의 주요 지표인 부모 커밋을 식별하는 데 중점을 둡니다.
또한, git log --merges 명령을 사용하여 리포지토리의 히스토리에서 병합 커밋만 효율적으로 나열하는 방법을 배우게 됩니다. 마지막으로, 이러한 방법을 비 병합 커밋에 적용하여 Git 에서 서로 다른 유형의 커밋을 구별하는 방법에 대한 이해를 굳힐 것입니다.
이 단계에서는 git show 명령을 사용하여 커밋의 세부 정보를 검사하고, 특히 부모 커밋에 중점을 두는 방법을 살펴보겠습니다. 부모 커밋을 이해하는 것은 프로젝트의 히스토리를 탐색하고 서로 다른 커밋이 어떻게 관련되어 있는지 이해하는 데 매우 중요합니다.
먼저, 프로젝트 디렉토리에 있는지 확인해 보겠습니다. 터미널을 열고 my-time-machine 디렉토리로 이동합니다.
cd ~/project/my-time-machine이제 git log를 사용하여 커밋 히스토리를 확인해 보겠습니다. 간결한 보기를 위해 --oneline 플래그를 사용합니다.
git log --oneline다음과 유사한 출력을 볼 수 있습니다 (커밋 해시는 다를 것입니다).
a1b2c3d (HEAD -> master) Send a message to the future이것은 첫 번째 커밋을 보여줍니다. 이제 git show를 사용하여 이 커밋의 세부 정보를 확인해 보겠습니다. git log 출력에서 커밋 해시 (예: a1b2c3d와 같은 짧은 문자열) 를 복사하여 아래 명령에서 YOUR_COMMIT_HASH를 대체합니다.
git show YOUR_COMMIT_HASH예를 들어, 커밋 해시가 a1b2c3d인 경우 다음을 실행합니다.
git show a1b2c3d출력은 커밋에 대한 정보 (작성자, 날짜, 커밋 메시지 및 커밋으로 도입된 변경 사항 포함) 를 표시하며 매우 자세합니다.
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Jane Doe <jane.doe@example.com>
Date: Mon Aug 7 10:00:00 2023 +0000
Send a message to the future
diff --git a/message.txt b/message.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/message.txt
@@ -0,0 +1 @@
+Hello, Future Me프로젝트 히스토리의 시작 부분인 첫 번째 커밋의 경우 출력에 "Parent" 줄이 없음을 알 수 있습니다. 이는 초기 커밋에는 부모가 없기 때문입니다. 즉, 프로젝트 히스토리의 루트입니다.
이후 단계에서 더 많은 커밋이 있으면 git show를 다시 사용하여 부모 커밋이 어떻게 표시되고 히스토리를 어떻게 연결하는지 확인합니다. 이 연결을 이해하는 것은 Git 이 시간에 따라 변경 사항을 추적하는 방식을 이해하는 데 기본입니다.
이 단계에서는 병합 커밋에 대해 배우고, git log --merges를 사용하여 프로젝트 히스토리에서 이러한 유형의 커밋만 특별히 보는 방법을 배우겠습니다. 병합 커밋은 서로 다른 브랜치의 변경 사항을 통합하는 특수한 커밋입니다.
현재, 프로젝트 히스토리는 매우 단순하며, 초기 커밋 하나만 있습니다. 아직 브랜치나 병합이 없습니다. 먼저 git log --merges를 실행하여 이를 확인해 보겠습니다.
~/project/my-time-machine 디렉토리에 있는지 확인합니다.
cd ~/project/my-time-machine이제 다음 명령을 실행합니다.
git log --merges병합을 수행하지 않았으므로 이 명령은 출력을 생성하지 않을 것입니다.
이것은 예상된 결과입니다! git log --merges 명령은 커밋 히스토리를 필터링하여 한 브랜치를 다른 브랜치로 병합한 결과로 생성된 커밋만 표시하도록 설계되었습니다.
이 명령이 작동하는 것을 보려면 새 브랜치를 만들고, 해당 브랜치에서 몇 개의 커밋을 만든 다음, 이를 다시 주 브랜치로 병합해야 합니다. 향후 랩에서 브랜치 및 병합에 대해 자세히 알아보겠습니다.
지금은 git log --merges가 프로젝트에서 서로 다른 개발 라인이 언제, 어떻게 결합되었는지 이해하는 강력한 도구라는 것을 이해하는 것이 중요합니다. 이는 여러 사람이 동시에 서로 다른 기능에 대해 작업하는 협업 환경에서 특히 유용합니다.
이 단계에서는 일반 커밋 (비 병합 커밋) 을 만들고, git log를 사용하여 병합 커밋 (아직 없지만, 향후 랩에서 다룰 예정) 과 비교하여 히스토리에 어떻게 나타나는지 확인합니다. 이를 통해 다양한 커밋 유형에 대한 이해를 굳힐 수 있습니다.
먼저, message.txt 파일에 작은 변경 사항을 적용해 보겠습니다. 다른 줄을 추가할 것입니다.
~/project/my-time-machine 디렉토리에 있는지 확인합니다.
cd ~/project/my-time-machine이제 echo 명령을 사용하여 파일에 새 줄을 추가합니다.
echo "Adding another line." >> message.txt>> 연산자는 텍스트를 덮어쓰는 대신 파일에 추가합니다.
파일의 내용을 확인해 보겠습니다.
cat message.txt다음과 같은 내용을 볼 수 있습니다.
Hello, Future Me
Adding another line.이제, 저장소의 상태를 확인해 보겠습니다.
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 은 우리가 변경한 사항을 인식합니다. 이제 이 변경 사항을 스테이징하고 커밋해 보겠습니다.
git add message.txt
git commit -m "Add a second line to message"커밋을 확인하는 출력을 볼 수 있습니다.
[master a1b2c3d] Add a second line to message
1 file changed, 1 insertion(+)이제 git log --oneline을 사용하여 커밋 히스토리를 다시 살펴보겠습니다.
git log --oneline두 개의 커밋을 볼 수 있습니다.
e4f5g6h (HEAD -> master) Add a second line to message
a1b2c3d Send a message to the future최신 커밋 (e4f5g6h는 이 예시에서, 해시는 다를 것입니다) 은 우리의 새로운 비 병합 커밋입니다. 이는 master 브랜치에서 직접 이루어진 단일 변경 사항을 나타냅니다.
git log --merges를 다시 실행하면, 이 커밋 중 어느 것도 병합 커밋이 아니기 때문에 여전히 출력이 표시되지 않습니다.
일반 커밋과 병합 커밋의 차이점을 이해하는 것은 프로젝트의 히스토리를 해석하고 다른 사람들과 효과적으로 협업하는 데 중요합니다. 일반 커밋은 단일 개발 라인에서 선형적인 진행을 나타내고, 병합 커밋은 서로 다른 라인의 변경 사항 통합을 나타냅니다.
이 랩에서는 Git 에서 병합 커밋을 식별하는 방법을 배웠습니다. 먼저, git show 명령을 사용하여 커밋의 세부 정보를 검사하고, 특히 부모 커밋의 존재 여부에 중점을 두었습니다. 초기 커밋에는 부모가 없지만, 후속 커밋에는 부모 커밋이 표시된다는 것을 확인했습니다.
그런 다음, 저장소의 히스토리에서 병합 커밋만 나열하는 직접적인 방법인 git log --merges 명령을 살펴보았습니다. 마지막으로, 이러한 방법들을 비 병합 커밋에 적용하여, 해당 커밋들이 올바르게 식별되는지 확인하여, 병합 커밋과 일반 커밋을 구별하는 방법에 대한 이해를 굳혔습니다.
