기존 git 저장소를 Github로 밀면 커밋의 약 절반 만 보냅니 까?

StackOverflow https://stackoverflow.com/questions/237408

  •  04-07-2019
  •  | 
  •  

문제

나는 며칠 동안 개발 한 로컬 git 저장소를 가지고 있습니다. 지금까지 18 개의 커밋이 있습니다. 오늘 밤, 나는 그것을 밀고 싶었던 개인 github 저장소를 만들었습니다. 그러나 내가 그렇게했을 때, 그것은 18 개의 커밋 중 8 개를 Github로 밀어 붙였습니다. 나는 Github Repo를 삭제하고 동일한 결과로 retried.

왜 이런 일이 일어날 지에 대한 생각이 있습니까? 나는 몇 번이나 성공하지 않고이 절차를 수행했기 때문에 약간 혼란스러워했습니다.

업데이트:이 저장소에는 마스터 브랜치 만 있습니다. 게시 된 답변 중 몇 가지를 해결하기 위해 ...

도움이 되었습니까?

해결책

나는 문제의 저장소를 살펴 보았고 다음은 다음과 같습니다.

  • 어느 시점에서 RPJ가 공연했습니다 git checkout [commit id]. 이것은 인정 된 지점이 아닌 느슨한 커밋을 지적했습니다. 나는 이것이 Cesarb가 언급하는 "매달린 머리"문제라고 생각합니다.
  • 이 문제를 깨닫지 못했지만, 그는 그들을 바꾸고 헌신하는 일을 계속했습니다. 그러나 헤드는 인정 된 지점이 아니라 매달려있는 커밋 체인을 가리키고있었습니다.
  • 그가 변화를 밀었을 때, Git은 모든 것을 주인의 정상까지 밀어 넣었습니다. 이것은 현재 나무의 절반에 불과했습니다.
  • 혼란이 계속되었습니다

이 다이어그램은 더 명확하게 만들어야합니다.

                 -- D -- E -- F
                /             ^
   A -- B -- C -              |
   ^         ^               HEAD
   |         |
 remote    master

그가 그의 변화를 추진하려고 할 때만 A ~을 통해 C 밀려 났고 remote 위로 올라 갔다 C. 그는 커밋을받을 수 없었다 D ~을 통해 F 알려진 지점에서 참조되지 않기 때문에 밀어 붙입니다.

이 상태에있을 때 보는 것은 다음과 같습니다.

$ git branch
* (no branch)
master

해결책은 움직이는 것입니다 master 까지 F 매달린 커밋 체인에서. 내가 한 방법은 다음과 같습니다.

  • 현재 상태에 대한 합법적 인 지점을 만듭니다.

    git checkout -b tmp

    • 그만큼 tmp 지점은 이제 Commit을 가리키고 있습니다 F 위의 다이어그램에서

  • 빨리 감기 master 에게 tmp

    git checkout master

    git merge tmp

    • master 이제 커밋을 가리키고 있습니다 F.

  • 임시 지점을 버리십시오

    git branch -d tmp

  • 원격 저장소로 행복하게 밀 수 있으며 모든 변경 사항을 보내야합니다.

다른 팁

GIT 1.7.3에서 하나의 간단한 명령 으로이 작업을 수행 할 수 있습니다.

git checkout -B master

그만큼 -b 스위치는“체크 아웃하기 전에 여기서 지점을 만듭니다”를 의미하고 -B "분기가 이미 존재하더라도 -이 경우에 여기에서 옮기기 전에 여기로 이동하십시오"라는 무조건 버전입니다.

이런 종류의 문제를 해결하기위한 매우 간단한 접근 방식은 master 분기하고 그것을 재현하십시오. 결국, git의 지점은 단지 커밋의 이름 일뿐입니다. master 지점은 특별한 것이 아닙니다.

그래서 현재 커밋이 당신이 원하는 것이라고 가정합니다. master 당신은 단순히 그렇게합니다

git branch -D master

기존을 삭제합니다 master 그때는 그렇습니다

git checkout -b master

a) 새 지점을 만듭니다 master 현재 커밋 및 b) 업데이트를 가리 킵니다. HEAD 지적합니다 master 나뭇가지. 이후, HEAD 첨부됩니다 master 따라서 master 당신이 커밋 할 때마다 앞으로 나아갈 것입니다.

올바른 지점을 밀고 있고 가지가 실제로 생각하는 것을 가지고 있는지 확인하십시오. 특히, 분리 된 헤드가 없는지 확인하십시오. 의도적으로 수행하지 않으면 혼란 스러울 수 있습니다.

가장 쉬운 확인 방법은 사용하는 것입니다 gitk --all, 모든 가지, 머리 등을 그래픽으로 보여줍니다.

내가 가장 먼저 할 일은 달리는 것 같아요 git fsck 로컬 저장소에서 모든 것이 양호한 지 확인하십시오.

나는 전에이 문제를 본 적이 없으며 무엇이 잘못되었는지 생각할 수 없습니다.

Cesarb의 이전 답변에 직접 언급 할 명성이 없지만 gitk --all 이 경우 알려진 분기 만 나열되어 있으므로 작동하지 않습니다.

gitk HEAD 이 문제를 보여 주지만 완전히 명확하지는 않습니다. 흡연 총은 그게 다 master 가장 최근의 커밋보다는 커밋 트리 아래에 나타납니다.

따라서, .git/refs/heads/mas 그 점에서 나는 그것이 단지 올라가서 .git/refs/heads/master에 지정된 Commit 해시를 포함한다는 것을 의미합니다.

이 파일 (손으로)을 수정하고 Github로 다시 밀어 넣으면 모든 것이 다시 그레이비였습니다. 나는 아직도있다 몰라요 이 상태에서 일을하게 된 일이 있었지만 적어도 수정 사항을 알아 냈습니다.

누구나 궁금한 점이있는 경우 : .git/refs/heads/mas .git/logs/head의 내용을 .git/logs/refs/heads/master로 복사했습니다. 쉬운 족제비 ... 아니에요.

나는이 같은 문제를 두 번 가지고 있었고 마침내 내가하고있는 일을 알아 냈습니다. 오래된 커밋을 편집하는 과정에서 git rebase -i, 전화하는 대신 git commit --amend, 나는 전화했다 git commit -a 습관의 힘으로 즉시 그 뒤를 이어 git rebase --continue, 물론이야. 다른 사람이 무대 뒤에서 무슨 일이 일어나고 있는지 설명 할 수 있지만 결과는 분리 된 헤드 문제인 것 같습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top