git commit integrity

git commit이 무엇인지, 어떤 부분이 commit의 sha 해시에 참여하는지 검색하려고했습니다. 하지만 아마 내가 찾은 단어를 잘못 묻는 것 같습니다.git commit integrity

어떤 커밋으로 구성되어 있는지 궁금합니다. 나는 이미지가 따르는 사회 책을 조금 읽고 :

enter image description here

그러나 나는 그림에 표시된 것보다 더 많은 필드가 커밋 생각합니다.

이제 주요 질문 : 어떤 필드가 커밋 sha 해시에 참여합니까? 같은 sha 해쉬를 가진 다른 저장소에서 두 개의 커밋을 얻었지만, 다른 커밋을 사용했다. 그 전에 나는 두 개의 커밋이 같고 동일한 커밋을 가지고 있다면 같은 sha hash를 가질 수 있다고 생각했다. 그래서 나는 약간 혼란 스럽다.

두 개의 로컬 리포지토리 (git1, git2)가 있습니다. 하나는 다른 하나의 복제본입니다.

git1 범

commit 4f438f9579939312689eb67e5fb7957d87cfa036 <-- this commit 
Author: Michael Nesterenko <[email protected]> 
Date: Mon Jun 25 00:00:31 2012 +0300 

    stuff after change 

commit e91e833158bb44f54f418cc5c3e1832452051428 
Merge: dc69dc2 0b5912b 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:09:18 2012 +0300 

    Merge branch 'master' of e:/temp/git2 

    Conflicts: 
     file.file 

commit 0b5912bd1a1cb9b78410fe5c0dc67845ca1deec5 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:46 2012 +0300 

    c8 

commit dc69dc25a1e0c9067cbca19fe6a1d078a19138a0 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:29 2012 +0300 

    c7 

commit f6d88da1ecc3106f6debe1eac80d4b02705bcecf 
Merge: d1a3c38 6134e66 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:05:05 2012 +0300 

    Merge branch 'master' of e:/temp/git1 

    Conflicts: 
     file.file 

commit d1a3c389416ff88e195e93def9a956fad1e63819 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:03:47 2012 +0300

git2

commit e1ee3b2756d4d8440ae3661df3fb3ec9af7cd55a 
Merge: 4296e1b 4f438f9 
Author: Michael Nesterenko <[email protected]> 
Date: Mon Jun 25 00:01:30 2012 +0300 

    Merge branch 'master' of e:/temp/git1 

    Conflicts: 
     file.file 

commit 4f438f9579939312689eb67e5fb7957d87cfa036 <-- this commit 
Author: Michael Nesterenko <[email protected]> 
Date: Mon Jun 25 00:00:31 2012 +0300 

    stuff after change 

commit 4296e1bd046c4008166cfc516ef5ee2ce98a27d1 
Author: Michael Nesterenko <[email protected]> 
Date: Sun Jun 24 23:57:14 2012 +0300 

    more stuff 

commit e91e833158bb44f54f418cc5c3e1832452051428 
Merge: dc69dc2 0b5912b 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:09:18 2012 +0300 

    Merge branch 'master' of e:/temp/git2 

    Conflicts: 
     file.file 

commit 0b5912bd1a1cb9b78410fe5c0dc67845ca1deec5 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:46 2012 +0300 

    c8 

commit dc69dc25a1e0c9067cbca19fe6a1d078a19138a0 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:29 2012 +0300

다른 부모하지만 같은 샤 해시를 가지고있다.

출처

2012-06-24 michael nesterenko

커밋에 각 저장소에 다른 부모가 있다고 생각합니까? 각 저장소에'git cat-file commit 4f438f9579939312689eb67e5fb7957d87cfa036'의 결과를 보여주십시오. 또한 게시 한 출력을 생성하기 위해 어떤 log 명령을 실행 했습니까? –

@CharlesBailey, 로그 출력으로 생각하게 만들었습니다. 그러나 어떤 이유에서 두 저장소에서'git log'는'4f438f9579939312689eb67e5fb7957d87cfa036'에 대해 같은 부모 커밋을 보여줍니다. 기묘한!'git1'에는'e91e833158bb44f54f418cc5'가 있고'git2'에는'4296e1bd046c4008166cfc516ef5ee2ce98a27d1'이 있습니다. –

어떤 옵션을 사용하여 기록 했습니까? '--graph'와 같은 일을하지 않으면 실제 부모 관계를 볼 수 없으며 합리적으로 논리적 인 순서로 요청한 모든 커밋을 볼 수 있지만 다른 커밋 전에 커밋이 있는지를 확신 할 수는 없습니다 직계 후손. –

동일한 저장소의 복제본에있는 두 개의 서로 다른 커밋이 동일한 ID이지만 커밋이 다르다는 것은 거의 불가능하지 않을 수 있습니다. 부모 목록 은 해시 된 커밋의 데이터 부분 인입니다. 커밋에 대한 데이터를 다음 <type> <size>\0 :

git cat-file commit <id-of-commit>

해시 된 실제 데이터로 구성된 헤더입니다 : 실행할 수있는 해시 된 데이터를 참조하십시오. 예 : A에 대한 내 자식 클론에서 커밋 :

$ printf 'commit %d\0' $(git cat-file commit 5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 | wc -c) >tmp.dat 
$ hexdump -C tmp.dat 
00000000 63 6f 6d 6d 69 74 20 33 30 34 00     |commit 304.| 
0000000b 
$ git cat-file commit 5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 >>tmp.dat 
$ sha1sum tmp.dat 
5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 tmp.dat

주를 sha1sum이 커밋 ID와 일치하고, 부모가 커밋 객체의 일부입니다

$ git cat-file commit 5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 | grep parent 
parent 3ba46634202968045e05e4d7f969d97c61efa53d

git log 커밋의 단순 목록을 출력 만에 위탁 git은 지시 된 비순환 그래프를 형성한다. 로그는 커밋의 평평한 목록이기 때문에 단순한 선형 기록의 사소한 경우에만 부모 관계에 커밋을 직접 반영합니다. 병합이 있거나 여러 분기를 로깅하는 경우 git log의 출력에서 상위 관계를 직접 유추 할 수 없습니다.

는 git log --graph 같은 것을 사용해야합니다 부모 (있는 내가 일반적으로 --oneline 권장) 또는 그래픽 시각화 도구 등 gitk 저지의 실제 링크를 표시합니다.

출처

2012-06-24 21:48:24

답변 해 주셔서 감사합니다. '자식 로그 (git log)'가 위와 같은 순서로 커밋을 정렬 할 수있는 이유를 설명해 주실 수 있습니까? 나는 항상 아래 커밋이 상위에 커밋을위한 부모 (또는 적어도 하나의 부모)라고 생각했다. –

그 행동을 반복 할 수 있습니다. 부모 커밋에는 아무런 문제가 없습니다. 그게'자식 로그'가 커밋을 표시하는 방법 인 것 같습니다. 이는 리포지토리 중 하나에서 하드 리셋 한 후 두 번째 리포지토리를 당긴 후에 발생합니다. –

@mishanesterenko : 로그는 커밋 목록입니다. 하나의 커밋이 다른 커밋 이후에 나타나는 것이 반드시 커밋 된 커밋의 부모라는 것을 의미하지는 않습니다. 'git log'는 부모 관계를 보여주지 않기 때문에 "wrong parent"를 보여주지 않습니다. 당신은 그것이 존재하지 않을 때 그 의미를 추론합니다. –

답변

관련 문제