다음을 통해 공유


Git 기록 단순화 이해

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Git 역사 단순화는 혼란스러운 짐승이 될 수 있습니다. 99% 당신은 심지어 존재 알 수 없습니다 시간의, 하지만 때때로 그것은 Git의 어두운 구석에서 뛰어 당신을 물린 것입니다. 이 문서에서는 기록 단순화의 정의와 파일 기록을 볼 때 어떻게 혼동을 일으킬 수 있는지 살펴보겠습니다.

일반적인 시나리오부터 시작해 보겠습니다.

  1. 변경 사항을 파일로 푸시한 다음 변경 사항을 기본으로 병합합니다.
  2. 동료 중 일부는 그들의 브랜치를 메인 브랜치에 병합합니다.
  3. 잠시 후에 돌아와서 변경 내용이 누락된 것을 알 수 있습니다.
  4. 범인을 찾기 위해, 당신은 파일 기록을 보고 알아차립니다... 변경 사항이 나열되지 않았다는 것을!

Git 커밋 기록은 트리입니다. 시간순 기록이 실제 파일 트리 기록과 동일하지 않은 경우도 있습니다. 이 상황은 병합 커밋이 파일을 원래 상태로 되돌릴 때 가장 자주 발생합니다. 이 경우 기술적으로 파일이 변경되지 않았기 때문에 기본 기록 보기에모든 변경 내용이 실제로 표시되지는 않습니다. 이 시나리오에서 Git은 기록을 간소화할 수 있으며 가장 가능성이 큰 "변경 내용"이 로그에서 제거된다는 것을 인식합니다.

이전에 이것을 경험한 적이 없다면, 좌절감을 느끼고 궁금해할 수 있습니다. 도대체 내 변화가 어디로 갔는가?

기록 단순화: 기본적으로 켜기

기본적으로 파일에서 로그 명령을 실행합니다. git log file.txt 자동으로 기록을 단순화하고 출력에서 일부 커밋을 숨길 수 있습니다. 자세한 내용은 git log man 페이지참조하세요.

혼동을 더하는 것은 실행하는 경우에도 역사 단순화가 git log 않는다는 것입니다. 왜냐하면 모든 변경 사항을 보고 있기 때문에 단순화할 것이 없기 때문입니다.

기록 단순화를 해제하려면 명령줄 스위치 --full-history사용해야 합니다.

기록 단순화의 예

단순화가 어떻게 작동하는지 더 잘 이해하기 위해, 우리는 역사 단순화의 우리 자신의 예를 만듭니다. 먼저 우리가 만들고자 하는 역사의 다이어그램을 한번 살펴보겠습니다.

Git 브랜치

여기서 볼 수 있듯이 다음을 수행합니다.

  1. 파일을 만듭니다.
  2. 분기(동물)의 해당 파일에 줄을 추가합니다.
  3. 다른 브랜치(과일)에서 해당 파일에 새로운 줄을 추가합니다.
  4. 동물 분기를 메인으로 다시 병합합니다.
  5. 브랜치 과일을 메인 브랜치로 다시 병합하고, 과일 브랜치에서 파일의 전체 사본을 선택합니다.
  6. 파일의 기록을 확인합니다.

Git은 우리에게 역사를 단순화할 것입니다. 여기서는 5단계가 핵심입니다. 우리는 동물 분기의 모든 변화를 무시했습니다. Git은 기본적으로 파일이 1단계와 5단계 사이에 변경되지 않았기 때문에 두 개의 기록 항목만표시됩니다.

먼저 파일을 만들고 리포지토리에 추가합니다.

> cd sample
> git init
> echo "some content" > test.txt
> git add test.txt
> git commit -m "Initial commit"

이제 동물 분기의 파일에 "당나귀" 텍스트를 추가하기로 결정했습니다.

> git checkout -b animals
> echo "donkeys" >> test.txt
> git commit -am "We have added an animal"

실험하는 동안 파일에서 과일을 대신 사용하려고 하므로 다른 분기를 만들고 파일 끝에 "바나나"라는 텍스트를 추가합니다.

> git checkout main -b fruit
> echo "bananas" >> test.txt
> git commit -am "We have added a fruit"

변경 사항에 만족하여, 우리는 우리의 동물 브랜치를 메인에 다시 병합하기로 결정했습니다.

> git checkout main
> git merge animals

이제 test.txt 파일의 로그를 살펴보겠습니다.

> git log test.txt
    
    commit 6b33d99b996c430a60c9552b79245d1aa8320339
        Date:   Mon Feb 15 10:45:33 2016 -0500

        We have added an animal

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

지금까지 잘 되고 있어요, 그렇죠? 로그 출력에서 이상한 점은 보이지 않습니다. 그럼 이제 생각을 바꿔서 과일 가지를 합치기로 결정했다고 가정해 봅시다.

>git merge fruit
    
    Auto-merging test.txt
    CONFLICT (content): Merge conflict in test.txt
    Automatic merge failed; fix conflicts and then commit the result.

아이고, 병합 충돌이 발생했습니다. 몇 가지 고려 끝에 우리는 과일 분기의 전체 파일 test.txt를 사용하기로 결정했습니다. 일반적으로 일종의 텍스트 편집기 또는 병합 도구를 사용하지만, 두 줄에 불과하므로 전체 파일만 다시 만듭니다.

> echo "some content" > test.txt
> echo "bananas" >> test.txt
> git commit -am "Fixed merge conflict"

이제 test.txt 파일의 기록을 살펴보겠습니다.

> git log test.txt
    
    commit fdd4dfd816c4efebc5bdb240f49e934e299db581
        Date:   Mon Feb 15 10:51:06 2016 -0500

        We have added a fruit

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

아니나 다를까, 로그에서 첫 번째 실험의 변경 사항이 보이지 않으며 병합도 역시 보이지 않습니다. 그들은 여전히 거기에 있습니까? Git에서 변경 내용을 완전히 제거했나요?

> git log --full-history test.txt

볼 수 있듯이 full-history 플래그 없이 로그를 간소화했지만 Git은 모든 변경 내용을 유지했습니다.

> commit 5d0bb77a24e265dc154654fb3b5be331b53bf977
    Merge: 6b33d99 fdd4dfd
        Date:   Mon Feb 15 10:59:34 2016 -0500

        Fixed merge conflict

    commit fdd4dfd816c4efebc5bdb240f49e934e299db581
        Date:   Mon Feb 15 10:51:06 2016 -0500

        We have added a fruit

    commit 6b33d99b996c430a60c9552b79245d1aa8320339
        Date:   Mon Feb 15 10:45:33 2016 -0500

        We have added an animal

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

Git 기록 단순화 요약

역사 단순화에 대한 것은 대부분의 경우 당신이 그것을 눈치 채지 못할 것이라는 것입니다. 그러나 병합 충돌이 잘못되어 어떤 일이 일어났는지 알고 싶을 때 git 로그 기록을 보고 변경 내용이 어디로 갔는지 궁금할 수 있습니다.

이제 당황하는 대신 다음을 알 수 있습니다.

  • 파일에 대한 기록 간소화는 기본적으로 설정되어 있습니다.
  • --full-history 플래그는 보다 포괄적인 파일 기록을 제공합니다.

업데이트: 이 문서를 작성한 이후로 Azure DevOps Services는 웹에서 다양한 멋진 기록 보기 옵션을 도입했습니다. 즉, 명령줄을 통해 로깅하지 않으려면 탐색기에서 기록을 보려는 파일을 끌어올 수 있으며 단순 또는 단순하지 않은 기록 보기를 지정할 수 있는 아래 기록 필터가 표시됩니다.

git 필터Git FiltersGit Filters

(c) 2016 Microsoft Corporation. 모든 권리 보유. 이 문서는 "as-is"으로 제공됩니다. URL 및 기타 인터넷 웹 사이트 참조를 포함하여 이 문서에 표현된 정보 및 보기는 예고 없이 변경될 수 있습니다. 이 문서의 사용으로 발생하는 위험은 귀하의 책임입니다.

이 문서는 Microsoft 제품의 지적 재산권에 대한 법적 권리를 제공하지 않습니다. 이 문서는 내부 참조용으로 복사 및 사용할 수 있습니다.