사진과 글로 자세한 설명! Git 작동 방식 이해

이 글은 Git의 작동 원리에 대한 관련 지식을 제공하며 주로 그림과 텍스트를 사용하여 자세히 설명합니다.

git 작동 방식 설명

이 문서에서는 Git에서 가장 일반적으로 사용되는 명령을 보여줍니다. Git의 작동 방식을 어느 정도 이해하고 계시다면 이 글을 통해 더욱 철저한 이해를 하실 수 있습니다.

위의 네 가지 명령은 작업 디렉터리, 준비 디렉터리(인덱스라고도 함) 및 웨어하우스 간에 파일을 복사합니다.

• git add files는 현재 파일을 준비 영역에 넣습니다.

• git commit은 스테이징 영역의 스냅샷을 생성하여 제출합니다.

• git Reset – 파일은 마지막 git add 파일을 실행 취소하는 데 사용됩니다. git 재설정을 사용하여 모든 준비 영역 파일을 실행 취소할 수도 있습니다.

• git checkout – 파일은 준비 영역에서 작업 디렉터리로 파일을 복사하여 로컬 수정 사항을 삭제합니다.

git Reset -p, git checkout -p 또는 git add -p를 사용하여 대화형 모드로 들어갈 수 있습니다.

대기 영역을 건너뛰고 창고에서 파일을 직접 검색하거나 코드를 직접 제출할 수도 있습니다.

• git commit -a는 git add를 실행하여 현재 디렉터리의 모든 파일을 준비 영역에 추가한 다음 실행하는 것과 같습니다.

• git 커밋 파일은 마지막 커밋과 작업 디렉터리에 있는 파일의 스냅샷을 포함하는 커밋을 만듭니다. 그리고 파일이 준비 영역에 추가됩니다.

• git checkout HEAD – 마지막 커밋을 복사하기 위해 파일을 롤백합니다.

다음 글에서는 사진이 아래와 같은 형태로 사용됩니다.

녹색 5자리 문자는 각각 상위 노드를 가리키는 제출된 ID를 나타냅니다. 분기는 주황색으로 표시되며 특정 커밋을 가리킵니다. 현재 분기는 연결된 HEAD로 식별됩니다. 이 사진은 지난 5개의 제출물을 보여 주며, ed489가 최신 제출물입니다. 마스터 브랜치는 이 커밋을 가리키고 다른 메인 브랜치는 상위 커밋 노드를 가리킵니다.

Diff

커밋 간의 변경 사항을 확인하는 방법에는 여러 가지가 있습니다. 다음은 몇 가지 예입니다.

Commit

제출 시 Git은 스테이징 영역의 파일을 사용하여 새 제출을 생성하고 이때 노드를 상위 노드로 설정합니다. 그런 다음 현재 분기가 새 커밋 노드를 가리키도록 합니다. 아래 그림에서 현재 브랜치는 마스터입니다. 명령을 실행하기 전에 마스터는 ed489를 가리킵니다. 제출 후 마스터는 ed489를 상위 노드로 사용하여 새 노드 f0cec를 가리킵니다.

현재 분기가 특정 제출의 상위 노드인 경우에도 git은 동일한 방식으로 작동합니다. 아래 그림에서는 master 브랜치의 할아버지 노드인 maint 브랜치에 커밋이 이루어지고 1800b가 생성됩니다. 이런 방식으로, 메인 브랜치는 더 이상 마스터 브랜치의 상위 브랜치가 아닙니다. 이때 병합[1](또는 리베이스[2])이 필요합니다.

커밋을 변경하려면 git commit –amend를 사용하세요. Git은 현재 커밋과 동일한 상위 노드를 사용하여 새 커밋을 만들고 이전 커밋은 취소됩니다.

또 다른 예는 HEAD 제출[3]을 분리하는 것입니다. 이에 대해서는 나중에 논의하겠습니다.

Checkout

체크아웃 명령은 기록 제출물(또는 준비 영역)에서 작업 디렉터리로 파일을 복사하는 데 사용되며 분기를 전환하는 데도 사용할 수 있습니다.

파일 이름이 지정되면(또는 -p 옵션이 켜져 있거나 파일 이름과 -p 옵션이 동시에 켜져 있는 경우) Git은 지정된 커밋에서 파일을 준비 영역으로 복사하고 작업합니다. 예배 규칙서. 예를 들어, git checkout HEAD~ foo.c는 제출 노드 HEAD~(즉, 현재 제출 노드의 상위 노드)에 있는 foo.c를 작업 디렉터리에 복사하고 이를 준비 영역에 추가합니다. (명령에 커밋 노드가 지정되지 않으면 스테이징 영역에서 콘텐츠가 복사됩니다.) 현재 분기는 변경되지 않습니다.

파일 이름이 지정되지 않았지만 (로컬) 분기가 제공되면 HEAD 식별이 해당 분기로 이동한 다음(즉, 해당 분기로 "전환") 스테이징 영역과 작업 디렉터리로 이동됩니다. 내용은 HEAD에 해당하는 제출 노드와 일치합니다. 새 제출 노드(아래 그림의 a47c3)에 있는 모든 파일이 준비 영역 및 작업 디렉터리로 복사됩니다. 이전 제출 노드(ed489)에만 존재하는 파일은 삭제됩니다. 위의 두 파일은 무시되며 영향을 받지 않습니다.

파일 이름이나 브랜치 이름을 지정하지 않고 레이블, 원격 브랜치, SHA-1 값 또는 master~3과 유사한 것을 지정하면 detached HEAD(분리 HEAD 식별자)라는 익명 브랜치를 얻게 됩니다. . 이를 통해 기록 버전 간에 쉽게 전환할 수 있습니다. 예를 들어, Git 버전 1.6.6.1을 컴파일하려는 경우 git checkout v1.6.6.1(브랜치 이름이 아닌 레이블)을 실행하고 컴파일하고 설치한 다음 다른 브랜치로 다시 전환할 수 있습니다. git checkout 마스터로. 그러나 커밋 작업에 "분리된 HEAD"가 포함되면 아래에 설명된 대로 동작이 약간 다릅니다.

공개 계정 "Java Backend Technology Full Stack"을 팔로우하여 인터뷰에 응하고, 질 높은 인터뷰 정보를 얻으세요

HEAD 식별자가 detached 상태일 때 작업 제출

HEAD가 있을 때 분리된 상태(어떤 브랜치에도 연결되지 않음)에서는 커밋 작업이 정상적으로 작동하지만 명명된 브랜치는 업데이트되지 않습니다. (익명 브랜치를 업데이트하는 것으로 생각할 수 있습니다.)

마스터와 같은 다른 브랜치로 전환하면 이 커밋 노드는 (아마) 다시는 참조되지 않고 폐기될 것입니다. 이 명령 이후에는 아무것도 2eecb를 참조하지 않습니다.

그러나 이 상태를 저장하려면 git checkout -b name 명령을 사용하여 새 브랜치를 생성할 수 있습니다.

Reset

Reset 명령은 현재 분기를 다른 위치로 가리키고 선택적으로 작업 디렉터리와 인덱스를 변경합니다. 또한 작업 디렉터리를 건드리지 않고 기록 저장소의 파일을 인덱스로 복사하는 데에도 사용됩니다.

옵션이 지정되지 않으면 현재 브랜치가 해당 커밋을 가리킵니다. -hard 옵션을 사용하면 작업 디렉터리도 업데이트되고, -soft 옵션을 사용하면 변경되지 않은 상태로 유지된다.

제출 지점의 버전 번호가 제공되지 않으면 기본적으로 HEAD가 사용됩니다. 이런 방식으로 분기점은 변경되지 않지만 인덱스는 마지막 커밋으로 롤백됩니다. –hard 옵션을 사용하면 작업 디렉터리는 동일합니다.

파일 이름(또는 -p 옵션)이 제공되면 인덱스가 업데이트된다는 점을 제외하면 작업 효과는 파일 이름을 사용한 체크아웃과 유사합니다.

Merge

Merge 명령은 다른 분기를 병합합니다. 병합하기 전에 인덱스는 현재 커밋과 동일해야 합니다. 다른 브랜치가 현재 커밋의 상위 브랜치인 경우 병합 명령은 아무 작업도 수행하지 않습니다. 또 다른 상황은 현재 커밋이 다른 브랜치의 상위 커밋이므로 빨리 감기 병합이 발생하는 경우입니다. 포인터가 이동되고 새 커밋이 생성됩니다.

그렇지 않으면 실제 합병입니다. 기본적으로 현재 커밋(아래 표시된 ed489)과 다른 커밋(33104) 및 공통 상위 노드(b325c) [4] 간에 3방향 병합이 수행됩니다. 결과는 현재 디렉터리와 인덱스를 먼저 저장한 다음 상위 노드 33104와 함께 새로운 커밋을 만드는 것입니다.

Cherry Pick

cherry-pick 명령은 커밋 노드를 "복사"하고 현재 분기에 동일한 새 커밋을 만듭니다.

리베이스

Rebase는 명령 병합의 대안입니다. 병합은 두 개의 상위 브랜치를 하나의 커밋으로 병합하며 커밋 기록은 선형이 아닙니다. 리베이스는 현재 브랜치의 다른 브랜치 기록을 재생하며 커밋 기록은 선형입니다. 본질적으로 이는 선형화된 자동 체리 따기입니다.

위 명령은 모두 마스터 브랜치가 아닌 토픽 브랜치에서 수행됩니다. 마스터 브랜치에서 반복하고 브랜치를 새 노드로 지정합니다. 이전 커밋은 참조되지 않으며 재활용됩니다.

롤백 범위를 제한하려면 –onto 옵션을 사용하세요. 다음 명령은 마스터 브랜치(2c33a)에서 169a6 이후 현재 브랜치의 마지막 몇 가지 커밋을 재생합니다.

커밋 삭제, 재배열, 수정, 병합과 같은 복잡한 작업을 보다 편리하게 완료할 수 있는 git rebase –interactive도 있습니다. 이를 보여주는 사진이 없습니다. 자세한 내용은 여기(git-rebase(1)[5])를 참조하세요.

파일 내용은 실제로 인덱스(.git/index)나 제출 객체에 저장되지 않고 데이터베이스(.git/objects)에 blob 형태로 저장되고 SHA-1 값으로 확인됩니다. 인덱스 파일에는 식별자와 함께 관련 Blob 파일 및 기타 데이터가 나열됩니다. 제출물은 트리 형태로 저장되며 해시 값으로 식별됩니다. 트리는 작업 디렉터리의 폴더에 해당하고, 트리에 포함된 트리 또는 Blob 개체는 해당 하위 디렉터리 및 파일에 해당합니다. 각 제출물은 상위 레벨 트리의 식별 코드를 저장합니다.

분리된 HEAD를 사용하여 제출하는 경우 마지막 제출은 HEAD의 참조 로그에서 참조됩니다. 그러나 시간이 지나면 무효화되고 git commit –amend 또는 git rebase와 마찬가지로 결국 재활용됩니다.

추천 학습: "Git Tutorial"

위 내용은 사진과 글로 자세한 설명! Git 작동 방식 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!