Git은 diff, 스냅샷 또는 기록을 커밋합니까?

나는 Git 커밋이 어떻게 구현되는지 이해하기 쉽지만 다른 사람들이 커밋을 어떻게 보는지는 이해하기 어렵습니다. 그래서 나는 마스토돈에 관해 다른 사람들에게 몇 가지 질문을 했습니다.

Git 제출에 대해 어떻게 생각하시나요?

사람들에게 Git 커밋에 대해 어떻게 생각하는지 묻는 매우 비과학적인 설문조사를 실시했습니다. 스냅샷인지, 차이점인지, 아니면 이전의 모든 커밋 목록인지? (물론 셋 다라고 생각하는 게 합리적이지만 사람들의 메인이 궁금하네요

결과는 다음과 같습니다.

• 51% 차이
• 42% 스냅샷
• 4% 이전 커밋 내역
• 3% “기타”

Difference와 Snapshot에서 두 옵션의 비율이 얼마나 가까운지 놀랐습니다. 사람들은 또한
“내가 보기에는 커밋이 다른 것 같지만 실제로는 스냅샷으로 구현된 것 같아요”,
“내가 보기에는 커밋이 스냅샷인 것 같지만 내 생각에는 실제로는 차이의 형태로 나타납니다.” 나중에 제출이 실제로 어떻게 구현되는지에 대해 자세히 설명하겠습니다.

더 나아가기 전에 "차이" 또는 "스냅샷"이란 무엇을 의미하나요?

차이점은 무엇인가요?

내가 말하는 "차이"는 아마도 매우 분명할 것입니다. 차이점은 달릴 때 얻게 되는 것입니다 git show COMMIT_ID . 예를 들어, 다음은 rbspy 프로젝트의 오타 수정입니다:

으아악

GitHub에서 볼 수 있습니다: https://github.com/rbspy/rbspy/commit/24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b

스냅샷이란 무엇인가요?

"스냅샷"이란 "실행할 때 얻는 모든 파일git checkout COMMIT_ID"을 의미합니다.

Git은 일반적으로 제출된 파일 목록을 "트리"(예: "디렉토리 트리")로 참조하며 위에 제출된 모든 파일을 GitHub에서 볼 수 있습니다.

https://github.com/rbspy/rbspy/tree/24ad81d2439f9e63dd91cc1126ca1bb5d3a4da5b (/tree/ 而不是 /commit/입니다)

Git이 어떻게 구현되는지 설명하는 것이 정말 맞는 표현인가요?

Git 학습에 관해 제가 듣는 가장 일반적인 조언은 아마도 "Git가 내부적으로 사물을 어떻게 표현하는지 배우면 모든 것이 더 명확해질 것입니다"라는 것입니다. 나는 분명히 이 관점을 많이 좋아합니다(이 블로그를 한동안 읽어보신 분이라면 제가 그것을 좋아한다는 것을 아실 것입니다

하지만 Git을 배우는 방법이 생각만큼 잘 안됐어요! 일반적으로 나는 "좋아, Git
커밋은 스냅샷이고 상위 커밋에 대한 포인터가 있고 브랜치는 커밋에 대한 포인터이고..."라고 신나게 설명하기 시작했지만 도움을 주려고 노력 중입니다. 사람들은 그 설명이 별로 유용하지 않다고, 아직도 이해하지 못한다고 말할 것입니다. 그래서 다른 옵션을 찾아봤습니다.

하지만 먼저 내부 구현에 대해 이야기해 보겠습니다.

Git이 내부적으로 커밋을 표현하는 방법 - 스냅샷

내부적으로 Git은 커밋을 스냅샷으로 나타냅니다(각 파일의 현재 버전의 "트리"를 저장함). 저는 Git 저장소에 있습니다. 파일은 어디에 있나요? 이에 대해 에서 썼지만 여기에 내부 형식에 대한 매우 간단한 개요가 있습니다.

제출 표현은 다음과 같습니다.

으아악

그리고 이 트리 개체를 보면 이 커밋의 저장소 루트 아래에 있는 모든 파일/하위 디렉터리 목록이 표시됩니다.

으아악

이는 Git 커밋을 체크아웃하는 것이 항상 빠르다는 것을 의미합니다. Git이 어제 커밋을 체크아웃하는 것은 백만 개의 커밋을 체크아웃하는 것만큼 쉽습니다. 커밋은 전혀 diff로 저장되지 않기 때문에 Git은 현재 상태를 확인하기 위해 10,000개의 diff를 다시 적용할 필요가 없습니다.

스냅샷은 packfile

을 사용하여 압축됩니다.

방금 Git 커밋은 스냅샷이라고 했는데 누군가 "내 생각엔 커밋은 스냅샷인데 구현의 차이인 것 같아"라고 하면
그것도 사실이에요! Git
커밋은 익숙한 diff 형식으로 표시되지 않습니다(이전 커밋과의 diff로 디스크에 저장되지 않음). 그러나 기본적인 직관은 10,000
을 수행하려는 경우입니다. line file 500번 편집하고 500개의 파일을 저장하는 것은 비효율적입니다.

Git에는 파일을 diff로 저장하는 방법이 있습니다. 이를 "팩파일"이라고 하며 Git은 디스크 공간을 절약하기 위해 주기적으로 데이터를 팩파일로 가비지 수집합니다. Git은 저장소를 git clone할 때 데이터를 압축합니다.

여기서는 팩파일 작동 방식을 완전히 설명할 공간이 부족합니다(Aditya Mukerjee의 "Unpacking Git packfiles"는 작동 방식을 설명하는 데 제가 가장 좋아하는 기사입니다). 그러나 델타의 작동 방식과 차이점과의 차이점에 대한 이해를 간략하게 요약할 수 있습니다.

• 객체는 "원본 파일" 및 "델타"에 대한 참조로 저장됩니다.
• 델타는 "0~100바이트를 읽은 다음 'hello there' 바이트를 삽입한 다음 120~200바이트를 읽습니다."와 같은 일련의 명령입니다. 원본 파일에서 새로운 텍스트를 모아줍니다. 따라서 "삭제"라는 개념은 없으며 복사 및 추가만 가능합니다.
• 델타 레벨이 적은 것 같아요. Git이 주어진 객체를 얻기 위해 얼마나 많은 델타 레벨을 거쳐야 하는지 확인하는 방법을 모르지만, 일반적으로 많지 않다는 느낌이 듭니다. 아마 10층도 안 되는 걸까요? 그래도 실제로 알아내는 방법을 알고 싶습니다.
• 원본 파일은 이전 커밋에서 가져온 것일 필요는 없으며 무엇이든 가능합니다. 어쩌면 나중에 커밋할 수도 있을까요? 잘 모르겠습니다.
• 변경 사항을 계산하는 데 "올바른" 알고리즘은 없습니다. Git에는 대략적인 경험적 방법이 있을 뿐입니다

차이점을 살펴보면 실제로 뭔가 이상한 일이 일어나고 있습니다

커밋의 차이점을 확인하기 위해 git show SOME_COMMIT실행할 때 실제로 일어나는 일은 약간 반직관적입니다. 내 이해는 다음과 같습니다.

Git은 팩 파일을 살펴보고 변경 사항을 적용하여 이 커밋과 상위 커밋의 트리를 다시 빌드합니다.

Git은 두 디렉터리 트리(현재 커밋의 디렉터리 트리와 상위 커밋의 디렉터리 트리) 간의 차이점 비교를 수행합니다. 일반적으로 거의 모든 파일이 정확히 동일하기 때문에 이 방법은 빠릅니다. 따라서 git은 거의 항상 아무것도 하지 않고 동일한 파일의 해시만 비교할 수 있습니다.

마지막으로 Git이 차이점을 보여줄 것입니다

그래서 Git은 변경 사항을 스냅샷으로 변환한 다음 차이를 계산합니다. 차이 같은 것에서 시작해서 차이 같은 것으로 끝나기 때문에 조금 이상하게 느껴지지만 변화의 정도와 차이는 사실 완전히 다르기 때문에 이해가 된다.

그렇기는 하지만 Git 저장소는 스냅샷으로 커밋을 저장하고 packfile은 디스크 공간을 절약하고 복제 속도를 높이기 위한 구현 세부 사항일 뿐이라고 생각합니다. 실제로 packfile이 어떻게 작동하는지 알 필요는 없었지만 Git 스냅샷이 디스크 공간을 너무 많이 차지하지 않고 커밋하는 방법을 이해하는 데 도움이 되었습니다.

Git의 "잘못된" 이해: 커밋은 차이가 있습니다.

Git의 "실수"에 대한 일반적인 이해는 다음과 같습니다.

• 커밋은 이전 커밋을 기반으로 한 diff로 저장됩니다(상위 커밋과 작성자 및 메시지에 대한 포인터 포함).
• 커밋의 현재 상태를 얻으려면 Git은 이전의 모든 커밋을 처음부터 다시 적용해야 합니다.

이러한 이해는 물론 잘못된 것입니다(실제로 커밋은 스냅샷 형식으로 저장되고 차이점은 이러한 스냅샷에서 계산됩니다). 그러나 나에게는 매우 유용하고 의미가 있는 것 같습니다! 병합 커밋에 대해 생각하면 조금 이상하지만 병합 커밋의 첫 번째 상위 커밋에 따른 차이일 뿐이라고 말할 수도 있습니다.

이러한 오해는 가끔 매우 유용하다고 생각하며 일상적인 Git 사용에는 문제가 되지 않는 것 같습니다. 우리가 가장 많이 사용하는 것(차이점)을 가장 기본적인 요소로 만드는 점이 정말 마음에 듭니다. 제게는 매우 직관적입니다.

저는 다음과 같이 Git에 대한 유용하지만 "잘못된" 다른 이해에 대해서도 생각해 왔습니다.

• 커밋 정보를 편집할 수 있습니다. (실제로 편집할 수 없습니다. 동일한 커밋을 복사하여 새 정보를 제공하면 이전 커밋이 여전히 존재합니다.)
• 커밋은 다른 베이스로 이동할 수 있습니다(마찬가지로 복사됩니다)

나는 Git에 대해 많은 "잘못된" 이해가 있지만 Git 사용자 인터페이스에서 주로 지원되며 대부분의 경우 문제를 일으키지 않는다고 생각합니다. 그러나 변경 사항을 취소하려고 하거나 문제가 발생하면 혼란스러울 수 있습니다.

제출물을 차이점으로 생각하면 얻을 수 있는 이점

Git에서는 커밋이 스냅샷이라는 것을 알고 있지만 대부분의 경우 커밋을 차이점으로 생각하는 이유는 다음과 같습니다.

• 대부분의 경우 내가 만들고 있는 변경 사항에 집중합니다. 만약 코드 한 줄만 변경한다면 분명히 전체 코드 베이스의 현재 상태보다는 해당 코드 줄에 대해 주로 생각하게 될 것입니다.
• GitHub에서 Git 커밋을 클릭하거나 git show를 사용하면 차이점을 확인할 수 있습니다. 따라서 이는 제가 익숙하게 본 것입니다.
• 저는 리베이스를 많이 사용합니다. 차이점을 다시 적용하는 것이 전부입니다

커밋을 스냅샷으로 처리하면 얻을 수 있는 이점

그러나 나는 때때로 다음과 같은 이유로 커밋을 스냅샷으로 생각합니다.

• Git은 파일 이동으로 인해 혼동되는 경우가 많습니다. 때로는 파일을 이동하고 편집하는데 Git이 해당 파일이 이동되었음을 인식하지 못하고 대신
  로 표시됩니다. "old.py가 제거되고 new.py가 추가되었습니다". Git은 스냅샷만 저장하기 때문에 "Move old.py -> new.py"라고 하면
  이때 old.py와 new.py의 내용이 유사하므로 추측일 뿐입니다.
• 이렇게 하면 git checkout COMMIT_ID무엇을 하는지 더 쉽게 이해할 수 있습니다(10,000개의 커밋을 다시 적용한다는 생각이 스트레스를 줍니다)
• 병합 커밋은 말 그대로 무엇이든 될 수 있기 때문에 나에게는 스냅샷처럼 보입니다(단지 새로운 스냅샷일 뿐입니다!). 병합 충돌을 해결할 때 왜 임의의 변경이 이루어질 수 있는지, 충돌을 해결할 때 주의를 기울여야 하는 이유를 이해하는 데 도움이 되었습니다.

제출에 대한 기타 이해

Mastodon의 답변 중 일부도 언급되었습니다:

• 이메일, GitHub 풀 요청, 동료와의 대화 등 커밋에 대한 "추가" 대역 외 정보
• '차이'를 '이전 상태 + 이후 상태'로 생각하세요
• 물론 많은 사람들은 상황에 따라 제출물을 다르게 봅니다

덜 모호한 커밋에 대해 이야기할 때 사람들이 사용하는 다른 단어:

• "수정"(스냅샷에 더 가깝습니다)
• "패치"(diff와 더 유사함)

그렇습니다!

Git에 대한 사람들의 이해가 서로 다르기 때문에 이해하기 어렵습니다. 특히 까다로운 점은 "잘못된" 이해가 종종 매우 유용함에도 불구하고 사람들은 "잘못된" 정신 모델을 경계하는 데 너무 열심이어서 일부 Git 해석자가 맞설 것이라는 두려움 때문에 "잘못된" 아이디어를 공유하기를 꺼린다는 것입니다. 나와서 그들이 왜 틀렸는지 설명하십시오. (이 Git
통역사는 일반적으로 좋은 의미를 갖고 있지만, 상관없이 부정적인 영향을 미칠 수 있습니다.)

하지만 많이 배웠어요! 커밋에 대해 어떻게 이야기해야 할지 아직 완전히 확신할 수는 없지만 결국에는 알아낼 것입니다.

Git 커밋에 대해 이야기해주신 Marco Rogers, Marie Flanagan 및 Mastodon의 모든 분들께 감사드립니다.

위 내용은 Git은 diff, 스냅샷 또는 기록을 커밋합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!