나는 Git 커밋이 어떻게 구현되는지 이해하기 쉽지만 다른 사람들이 커밋을 어떻게 보는지는 이해하기 어렵습니다. 그래서 나는 마스토돈에 관해 다른 사람들에게 몇 가지 질문을 했습니다.
사람들에게 Git 커밋에 대해 어떻게 생각하는지 묻는 매우 비과학적인 설문조사를 실시했습니다. 스냅샷인지, 차이점인지, 아니면 이전의 모든 커밋 목록인지? (물론 셋 다라고 생각하는 게 합리적이지만 사람들의 메인이 궁금하네요
결과는 다음과 같습니다.
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이 어제 커밋을 체크아웃하는 것은 백만 개의 커밋을 체크아웃하는 것만큼 쉽습니다. 커밋은 전혀 diff로 저장되지 않기 때문에 Git은 현재 상태를 확인하기 위해 10,000개의 diff를 다시 적용할 필요가 없습니다.
방금 Git 커밋은 스냅샷이라고 했는데 누군가 "내 생각엔 커밋은 스냅샷인데 구현의 차이인 것 같아"라고 하면
그것도 사실이에요! Git
커밋은 익숙한 diff 형식으로 표시되지 않습니다(이전 커밋과의 diff로 디스크에 저장되지 않음). 그러나 기본적인 직관은 10,000
을 수행하려는 경우입니다. line file 500번 편집하고 500개의 파일을 저장하는 것은 비효율적입니다.
Git에는 파일을 diff로 저장하는 방법이 있습니다. 이를 "팩파일"이라고 하며 Git은 디스크 공간을 절약하기 위해 주기적으로 데이터를 팩파일로 가비지 수집합니다. Git은 저장소를git clone할 때 데이터를 압축합니다.
여기서는 팩파일 작동 방식을 완전히 설명할 공간이 부족합니다(Aditya Mukerjee의 "Unpacking Git packfiles"는 작동 방식을 설명하는 데 제가 가장 좋아하는 기사입니다). 그러나 델타의 작동 방식과 차이점과의 차이점에 대한 이해를 간략하게 요약할 수 있습니다.
커밋의 차이점을 확인하기 위해git show SOME_COMMIT실행할 때 실제로 일어나는 일은 약간 반직관적입니다. 내 이해는 다음과 같습니다.
그래서 Git은 변경 사항을 스냅샷으로 변환한 다음 차이를 계산합니다. 차이 같은 것에서 시작해서 차이 같은 것으로 끝나기 때문에 조금 이상하게 느껴지지만 변화의 정도와 차이는 사실 완전히 다르기 때문에 이해가 된다.
그렇기는 하지만 Git 저장소는 스냅샷으로 커밋을 저장하고 packfile은 디스크 공간을 절약하고 복제 속도를 높이기 위한 구현 세부 사항일 뿐이라고 생각합니다. 실제로 packfile이 어떻게 작동하는지 알 필요는 없었지만 Git 스냅샷이 디스크 공간을 너무 많이 차지하지 않고 커밋하는 방법을 이해하는 데 도움이 되었습니다.
Git의 "실수"에 대한 일반적인 이해는 다음과 같습니다.
이러한 이해는 물론 잘못된 것입니다(실제로 커밋은 스냅샷 형식으로 저장되고 차이점은 이러한 스냅샷에서 계산됩니다). 그러나 나에게는 매우 유용하고 의미가 있는 것 같습니다! 병합 커밋에 대해 생각하면 조금 이상하지만 병합 커밋의 첫 번째 상위 커밋에 따른 차이일 뿐이라고 말할 수도 있습니다.
이러한 오해는 가끔 매우 유용하다고 생각하며 일상적인 Git 사용에는 문제가 되지 않는 것 같습니다. 우리가 가장 많이 사용하는 것(차이점)을 가장 기본적인 요소로 만드는 점이 정말 마음에 듭니다. 제게는 매우 직관적입니다.
저는 다음과 같이 Git에 대한 유용하지만 "잘못된" 다른 이해에 대해서도 생각해 왔습니다.
나는 Git에 대해 많은 "잘못된" 이해가 있지만 Git 사용자 인터페이스에서 주로 지원되며 대부분의 경우 문제를 일으키지 않는다고 생각합니다. 그러나 변경 사항을 취소하려고 하거나 문제가 발생하면 혼란스러울 수 있습니다.
Git에서는 커밋이 스냅샷이라는 것을 알고 있지만 대부분의 경우 커밋을 차이점으로 생각하는 이유는 다음과 같습니다.
git show를 사용하면 차이점을 확인할 수 있습니다. 따라서 이는 제가 익숙하게 본 것입니다.그러나 나는 때때로 다음과 같은 이유로 커밋을 스냅샷으로 생각합니다.
git checkout COMMIT_ID무엇을 하는지 더 쉽게 이해할 수 있습니다(10,000개의 커밋을 다시 적용한다는 생각이 스트레스를 줍니다)Mastodon의 답변 중 일부도 언급되었습니다:
덜 모호한 커밋에 대해 이야기할 때 사람들이 사용하는 다른 단어:
Git에 대한 사람들의 이해가 서로 다르기 때문에 이해하기 어렵습니다. 특히 까다로운 점은 "잘못된" 이해가 종종 매우 유용함에도 불구하고 사람들은 "잘못된" 정신 모델을 경계하는 데 너무 열심이어서 일부 Git 해석자가 맞설 것이라는 두려움 때문에 "잘못된" 아이디어를 공유하기를 꺼린다는 것입니다. 나와서 그들이 왜 틀렸는지 설명하십시오. (이 Git
통역사는 일반적으로 좋은 의미를 갖고 있지만, 상관없이 부정적인 영향을 미칠 수 있습니다.)
위 내용은 Git은 diff, 스냅샷 또는 기록을 커밋합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
