매달려있는 커밋 및 블랍에 대한 기본 정보를 찾고 있습니다.
내 레포는 괜찮은 것 같습니다. 그러나 나는 git fsck그것이 무엇을했는지 알기 위해 처음으로 달려 왔으며 'dangling blobs'와 하나의 'dangling commit'이라는 긴 목록이 있습니다.
이것들은 무엇입니까? 저들은 어디서 왔어요? 저의 레포 상태에 대해 비정상적인 (좋은지 나쁜지) 나타내는 것이 있습니까?
힘내 : 매달려 커밋 / 블롭이란 무엇이며 어디에서 왔습니까?
답변:
git 리포지토리를 사용하는 과정에서 작업이 중단되고 중간 블로 브를 유발하는 다른 동작을 수행하고 git이 정보 손실을 피하기 위해 수행하는 일부 작업을 수행 할 수 있습니다.
결국 (조건부로 git gc 매뉴얼 페이지 에 따르면 ) 가비지 수집을 수행하고 이러한 것들을 정리합니다. 가비지 수집 프로세스를 호출하여 강제로 실행할 수도 있습니다 git gc.
이에 대한 자세한 내용은 git-scm 사이트의 유지 관리 및 데이터 복구 를 참조하십시오 .
GC를 수동으로 실행하면 기본적으로이 안전망 명령이 실행되기 2 주 전에 종료됩니다. 실제로 GC를 실행하여 git 저장소를 잘 사용하는 것이 좋습니다. 그러나 무엇보다도 중요한 일을 없애기 전에 그 일을 이해해야합니다.
그것은 공정한 평가 일 것입니다.
—
vgoff
또한 파일을 'git add'할 때마다 정확한 버전의 파일을 커밋하지 않으면 매달린 얼룩이 생깁니다. 걱정할 것이 없습니다.
—
canton7
doub1ejack-일반적으로 가비지 콜렉션을 수동으로 실행해서는 안됩니다. 어쨌든 필요한 경우 git 가비지 수집을 수행하는 것은 나쁜 습관입니다. 수동으로 실행하는 것의 단점은 매달려있는 얼룩을 복구 할 수있는 능력을 잃어 버리고 지금은 원하지 않지만 앞으로는 원할 수 있다는 커밋입니다. 가비지 수집을 실행하면 git에서 강력한 강력한 되돌리기 기능을 제거합니다. 규칙이 아닌주의해서 예외적으로 사용하십시오. --- 그냥 자식에게 맡기세요.
—
Elijah Lynn
Dangling Blob = 준비 영역 / 인덱스로 변경되었지만 커밋되지 않은 변경 사항입니다. git의 놀라운 점 중 하나는 일단 스테이징 영역에 추가되면이 블롭이 해시가 있기 때문에 커밋처럼 행동하기 때문에 언제든지 다시 가져올 수 있다는 것입니다!
Dangling commit = 자식 커밋, 브랜치, 태그 또는 다른 참조에 의해 직접 연결되지 않은 커밋. 이것도 다시 얻을 수 있습니다!
'조상'이 '자손'을 읽어야합니까? 일반적으로 조상을 통해 git commit에 도달 할 수 없습니다.
—
Phil Miller
@Novelocrat 나는 같은 생각을 가지고 있었을 것입니다.
—
stkent
나는 아직도 당신의 대답에서 "오름차순"을 읽습니다. 7 월 2 일 이후의 판에서 오타가 수정되지 않은 것 같습니다.
—
iclman
매달려있는 얼룩을 어떻게 되찾습니까?
—
HelloGoodbye
@ElijahLynn 당신이 맞아요. 토론 내용을 너무 빨리 읽은 것 같습니다. 매달려있는 커밋에는 자손 / 자식이 없으며 태그 또는 분기에서 참조되지 않습니다.
—
iclman
http://www.tekkie.ro/news/howto-remove-all-dangling-commits-from-your-git-repository/ 에서 git 저장소에서 모든 매달려있는 커밋을 제거하는 방법
git reflog expire --expire=now --all
git gc --prune=now
결국 필요하다고 판단 할 수 있으므로 실제로 제거해야합니다.
실제로 대부분의 사용자는이를 필요로하지 않아야하며, 그렇게하는 경우 프로그래밍 방식의 사용 사례 일 것입니다. 매달려 커밋을 제거하여 디스크 공간을 절약하거나 속도를 높이는 것은 내 의견으로는 노력할 가치가 없습니다.
—
Elijah Lynn
이것은 다른 질문에 대한 답변입니다.
—
Elijah Lynn
매달려 커밋은 참조와 관련이없는 커밋입니다. 즉 도달 할 수있는 방법이 없습니다.
예를 들어 아래 다이어그램을 고려하십시오. 변경 사항을 병합하지 않고 분기 featureX를 삭제 한 다음 커밋 D는 연결된 참조가 없기 때문에 매달려 커밋이됩니다. 마스터로 병합 된 경우 HEAD 및 마스터 참조가 D를 커밋하도록 지정했으며 featureX를 삭제하더라도 더 이상 매달려 있지 않습니다. 이것을 이해하기 위해 다이어그램 뒤의 노트를 읽으십시오.
Git은 매달린 커밋을 자동으로 가비지 수집 (처리)합니다. 를 사용하여 git reflog병합하지 않고 삭제 된 분기 커밋의 분기를 복구 할 수 있습니다 . 삭제 된 커밋이 로컬 객체 저장소에있는 경우에만 복구 할 수 있습니다. 가비지 수집 된 경우 복구 할 수 없습니다.
참고 분기 이름 즉, 지점 라벨이 실제로 최신에 대한 참조이다는 가지의 끝 부분 즉, 나뭇 가지에 커밋합니다. 위의 다이어그램에서 featureX, master 및 HEAD는 특정 커밋에 대한 참조 일뿐입니다. featureX 및 마스터 레이블은 해당 분기의 최신 커밋을 나타냅니다. HEAD는 일반적으로 현재 체크 아웃 된 브랜치 (이 경우 마스터)의 팁을 나타냅니다. 현재 브랜치에서 이전 커밋을 체크 아웃하면 HEAD는 분리 된 상태가됩니다. 즉 최신 커밋 대신 이전 커밋을 가리 킵니다. 또한 HEAD는 실제로 현재 분기 레이블을 가리키고 모든 분기 레이블은 항상 분기의 끝을 가리 키기 때문에 기호 참조라고합니다. 따라서 정상적인 상황에서 HEAD는 간접적으로 최신 커밋을 가리 킵니다.
따로, Git은 커밋 그래프 / 이력을 유향 비순환 그래프로 나타냅니다 . 각 커밋에는 부모에 대한 참조가 있습니다. 따라서 커밋 다이어그램의 화살표는 자식 커밋에서 부모 커밋으로 연결됩니다. 지점의 이전 커밋에 도달하려면 최신 자식 커밋에 대한 참조가 필요합니다.
PS- 위의 다이어그램과 이해는이 무료 과정 에서 얻은 것 입니다. 과정이 상당히 오래되었지만 지식은 여전히 관련이 있습니다.
git gc있으며 2) 매달려있는 비트가 정상적이고 이미 있기 때문에 전혀 걱정할 필요가 없습니다. 그들을 처리?