분리 된 HEAD를 마스터 / 원점과 어떻게 조정할 수 있습니까?

Git의 분기 복잡성에 익숙하지 않습니다. 나는 항상 단일 브랜치에서 작업하고 변경 사항을 커밋 한 다음 주기적으로 원격 원점으로 푸시합니다.

최근 어딘가에, 커밋 준비를 끝내기 위해 일부 파일을 재설정하고 나중에 rebase -i최근 로컬 커밋을 제거하기 위해 a 를 수행했습니다 . 나는 지금 잘 이해하지 못하는 상태에 있습니다.

내 작업 영역에서 git log내가 기대하는 것을 정확하게 보여줍니다. 나는 가고 싶지 않은 커밋과 새로운 커밋 등 올바른 기차를 타고 있습니다.

그러나 방금 원격 저장소로 푸시했으며 다른 점이 있습니다. 리베이스에서 죽인 커밋이 푸시되었고 로컬로 커밋 된 새 커밋이 없습니다.

"마스터 / 원본"이 HEAD와 분리되어 있다고 생각하지만 그 의미, 명령 줄 도구로 시각화하는 방법 및 수정 방법에 대해 100 % 명확하지 않습니다.

먼저 HEAD가 무엇인지 명확히하자 무엇인지, 분리되었을 때의 의미를 .

HEAD는 현재 체크 아웃 된 커밋의 심볼 이름입니다. HEAD가 분리되지 않은 경우 ( "정상" ¹ 상황 : 분기가 체크 아웃 된 경우) HEAD는 실제로 분기의 "ref"를 가리키고 분기는 커밋을 가리 킵니다. 따라서 HEAD는 지점에 "연결"됩니다. 새 커밋을 만들면 HEAD가 가리키는 분기가 새 커밋을 가리 키도록 업데이트됩니다. HEAD는 지점을 가리 키기 때문에 자동으로 수행됩니다.

• git symbolic-ref HEAD 수확량 refs/heads/master
  "마스터"라는 지점이 체크 아웃되었습니다.
• git rev-parse refs/heads/master 수율 17a02998078923f2d62811326d130de991d1a95a
  커밋은 마스터 브랜치의 현재 팁 또는 "헤드"입니다.
• git rev-parse HEAD또한 수율 17a02998078923f2d62811326d130de991d1a95a
  이것은 "심볼 심판"이라는 의미입니다. 다른 참조를 통해 객체를 가리 킵니다.
  (심볼 ref는 원래 심볼릭 링크로 구현되었지만 나중에 심 링크가없는 플랫폼에서 사용할 수 있도록 추가 해석을 통해 일반 파일로 변경되었습니다.)

우리는이 HEAD→ refs/heads/master→17a02998078923f2d62811326d130de991d1a95a

HEAD가 분리되면 분기를 통해 간접적으로 가리키는 대신 커밋을 직접 가리 킵니다. 분리 된 HEAD를 명명되지 않은 분기에있는 것으로 생각할 수 있습니다.

• git symbolic-ref HEAD 실패 fatal: ref HEAD is not a symbolic ref
• git rev-parse HEADyields 17a02998078923f2d62811326d130de991d1a95a
  상징적 인 참조가 아니기 때문에 커밋 자체를 직접 가리켜 야합니다.

우리는 HEAD →17a02998078923f2d62811326d130de991d1a95a

분리 된 HEAD로 기억해야 할 중요한 점은 커밋이 참조되지 않은 경우 (참조가 도달 할 수없는 경우) 다른 커밋을 체크 아웃 할 때 "매달리게"됩니다. 결국, 이러한 댕글 링 커밋은 가비지 수집 프로세스를 통해 정리됩니다 (기본적으로 2 주 이상 유지되며 HEAD의 reflog에서 참조하여 더 오래 유지 될 수 있음).

¹ HEAD가 분리 된 상태에서 "정상적인"작업을하는 것은 완벽합니다. 리플 로그에서 기록을 삭제하지 않기 위해하는 일을 추적해야합니다.

인터랙티브 리베이스의 중간 단계는 분리 된 HEAD (부분적으로 활성 브랜치 reflog의 오염을 피하기 위해)로 수행됩니다. 전체 리베이스 작업을 마치면 리베이스 작업의 누적 결과로 원래 분기를 업데이트하고 HEAD를 원래 분기에 다시 연결합니다. 제 생각에는 리베이스 프로세스를 완전히 완료 한 적이 없습니다. 그러면 rebase 작업으로 가장 최근에 처리 된 커밋을 가리키는 분리 된 HEAD가 남게됩니다.

상황을 복구하려면 분리 된 HEAD가 현재 가리키는 커밋을 가리키는 분기를 작성해야합니다.

git branch temp
git checkout temp

_{(이 두 명령은로 축약 될 수 있습니다 git checkout -b temp)}

그러면 HEAD가 새 temp분기에 다시 연결됩니다 .

다음으로, 현재 커밋 (및 히스토리)과 정상 작동하는 분기를 비교해야합니다.

git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp
git diff master temp
git diff origin/master temp

(아마도 로그 옵션을 시험 해보고 싶을 것입니다 : add -p, --pretty=…전체 로그 메시지를 보려면 떠나십시오 .)

새 temp지점이 좋아 보인다면이 master를 가리 키도록 업데이트 (예 :) 할 수 있습니다.

git branch -f master temp
git checkout master

_{(이 두 명령은로 축약 될 수 있습니다 git checkout -B master temp)}

그런 다음 임시 분기를 삭제할 수 있습니다.

git branch -d temp

마지막으로, 당신은 아마 다시 설립 된 역사를 추진하고 싶을 것입니다 :

git push origin master

--force원격 브랜치를 새 커밋으로 "빨리 전달"할 수없는 경우 (예 : 기존 커밋을 삭제하거나 다시 쓰거나, 약간의 히스토리를 다시 쓰지 못함) 푸시하려면이 명령의 끝에 추가해야 할 수도 있습니다.

리베이스 작업 도중에 있다면 정리해야합니다. 디렉토리를 찾아 리베이스가 진행 중인지 확인할 수 있습니다 .git/rebase-merge/. 해당 디렉토리를 삭제하여 진행중인 리베이스를 수동으로 정리할 수 있습니다 (예 : 활성 리베이스 작업의 목적과 컨텍스트를 더 이상 기억하지 않는 경우). 일반적으로을 사용 git rebase --abort하지만 피할 수있는 추가 재설정을 수행합니다 (HEAD를 원래 분기로 다시 이동하고 원래 커밋으로 다시 설정하여 위에서 수행 한 작업 중 일부를 취소합니다).

그냥 이렇게 :

git checkout master

또는 유지하려는 변경 사항이있는 경우 다음을 수행하십시오.

git checkout -b temp
git checkout -B master temp

나는이 문제에 부딪 쳤고 가장 인기있는 답변을 읽을 때 :

HEAD는 현재 체크 아웃 된 커밋의 심볼 이름입니다.

나는 생각했다 : 아하! 경우 HEAD기호 이름이 저지를 체크 아웃 currenlty을 위해, 나는에 대해 그것을 조정할 수 있습니다 master에 대해 그것을 리베이스로 master:

git rebase HEAD master

이 명령은

1. 체크 아웃 master
2. 식별의 부모 커밋 HEAD시점에 다시 HEAD에서 분기master
3. 그 커밋을 재생합니다 master

결과적으로 모든 커밋 은 다음에 포함 HEAD되지 않은 결과입니다 . 체크 아웃 된 상태로 유지됩니다.mastermastermaster

리모컨에 관하여 :

리베이스에서 내가 죽인 커밋 몇 개가 밀려 났고 로컬에 커밋 된 새로운 커밋이 없습니다.

더 이상 로컬 히스토리를 사용하여 원격 히스토리를 전달할 수 없습니다. git push -f원격 기록을 덮어 쓰려면 강제 푸시 ( )해야합니다. 공동 작업자가있는 경우 일반적으로 모든 사람이 같은 페이지에 있도록이를 조정하는 것이 좋습니다.

masterremote로 푸시 하면와 같은 커밋을 가리 키도록 origin원격 추적 분기 origin/master가 업데이트됩니다 master.

분리 된 헤드에 대한 기본 설명은 여기를 참조하십시오.

http://git-scm.com/docs/git-checkout

그것을 시각화하는 명령 줄 :

git branch

또는

git branch -a

다음과 같이 출력됩니다.

* (no branch)
master
branch1

* (no branch)당신이 분리 된 머리에 있는 쇼.

git checkout somecommit등 을 수행하여이 상태에 도달했을 수 있으며 다음과 같이 경고했을 것입니다.

'분리 된 HEAD'상태입니다. 둘러보고 실험적으로 변경하고 커밋 할 수 있으며 다른 체크 아웃을 수행하여 분기에 영향을주지 않고이 상태에서 커밋을 버릴 수 있습니다.

생성 한 커밋을 유지하기 위해 새 브랜치를 만들려면 checkout 명령과 함께 -b를 다시 사용하여 지금 만들거나 나중에 할 수 있습니다. 예:

자식 체크 아웃 -b new_branch_name

이제 마스터로 가져 오려면

DO가 git reflog도 단지 또는 git log당신의 커밋을 확인합니다. 지금 git checkout master그리고 git merge커밋.

git merge HEAD@{1}

편집하다:

추가하려면 git rebase -i필요하지 않은 커밋을 삭제 / 죽일뿐만 아니라 편집에도 사용하십시오. 커밋 목록에서 "편집"을 언급하면 ​​커밋을 수정 한 다음 a git rebase --continue를 발행 할 수 있습니다. 이렇게하면 분리 된 HEAD에 들어오지 않았을 것입니다.

분리 된 커밋을 자체 브랜치에 가져 오기

간단히 실행 git checkout -b mynewbranch .

그런 다음를 실행 git log하면 커밋이 이제이 HEAD새 분기에 있음을 알 수 있습니다.

마스터 브랜치를 가지고 있고 "개발"으로 돌아가거나 기능을 원한다면 다음과 같이하십시오.

git checkout origin/develop

참고 : origin / develop 확인하십시오 .

HEAD 상태 가 분리 되었습니다 . 주변을 둘러보고 실험적으로 변경하고 커밋 할 수 있으며 다른 체크 아웃을 수행하여 분기에 영향을 미치지 않고이 상태에서 커밋을 버릴 수 있습니다 ...

그때

git checkout -b develop

효과가있다 :)

현재 분리 된 HEAD를 푸시하려면 ( git log이전에 확인 ) 다음을 시도하십시오.

git push origin HEAD:master

분리 된 HEAD를 원점에서 마스터 브랜치로 보냅니다. 푸시가 거부되면 git pull origin master먼저 변경 사항을 원점에서 가져 오십시오. 의도적 인 리베이스를 수행하고 원산지 / 마스터를 현재 분리 된 브랜치로 바꾸려고했기 때문에 원산지 변경 사항에 신경 쓰지 않고 거부 된 경우 강제로 할 수 있습니다 ( -f). 이전 커밋에 대한 액세스 권한을 잃어버린 경우 언제든지 git reflog모든 분기의 히스토리를 볼 수 있습니다 .

변경 사항을 유지하면서 마스터 브랜치로 돌아가려면 다음 명령을 시도하십시오.

git rebase HEAD master
git checkout master

참조 : 힘내 "아니 현재 어느 지점에." 변경 사항을 유지하면서 지점으로 돌아갈 수있는 쉬운 방법이 있습니까?

검색 할 때이 질문을 찾았습니다 You are in 'detached HEAD' state.

내가 과거에했던 것과 비교하여 내가 여기에했던 것을 분석 한 후, 내가 실수 한 것을 발견했다.

내 정상적인 흐름은 다음과 같습니다

git checkout master
git fetch
git checkout my-cool-branch
git pull

이번에는 내가했다 :

git checkout master
git fetch
git checkout origin/my-cool-branch
# You are in 'detached HEAD' state.

문제는 내가 실수로했다는 것입니다.

git checkout origin/my-cool-branch

오히려 :

git checkout my-cool-branch

(내 상황에서) 수정은 단순히 위의 명령을 실행 한 다음 흐름을 계속하는 것입니다.

git checkout my-cool-branch
git pull

다음은 나를 위해 일했습니다 (분기 마스터 만 사용).

git push origin HEAD:master
git checkout master        
git pull

첫 번째는 분리 된 HEAD를 원격 원점으로 푸시합니다.

두 번째는 지점 마스터로 이동합니다.

세 번째는 분기 마스터에 연결된 HEAD를 복구합니다.

푸시가 거부되면 첫 번째 명령에서 문제가 발생할 수 있습니다. 그러나 이것은 더 이상 헤드 분리 문제가되지 않지만 분리 된 HEAD가 일부 원격 변경을 인식하지 못한다는 사실에 관한 것입니다.

나는 오늘이 문제에 부딪 쳤고 다음을 수행하여 해결했다고 확신합니다.

git branch temp
git checkout master
git merge temp

이 작업을 수행하는 방법을 알아낼 때 회사 컴퓨터에 있었는데 이제는 개인용 컴퓨터에서 동일한 문제가 발생합니다. 월요일에 업무용 컴퓨터로 돌아와서 정확히 어떻게했는지 확인하려면 월요일까지 기다려야합니다.

HEAD가 양호한 상태라고 확신하는 경우 :

git branch -f master HEAD
git checkout master

당신의 주인이 원산지에서 벗어 났기 때문에 아마도 원산지로 밀 수 없습니다. 다른 사람이 repo를 사용하고 있지 않다고 확신하면 다음과 같이 강제 푸시 할 수 있습니다.

git push -f

다른 사람이 사용하지 않는 기능 분기에있는 경우 가장 유용합니다.

'git checkout [branch-name]'만 있으면됩니다. 여기서 [branch-name]은 분리 된 헤드 상태가 된 원래 분기의 이름입니다. (asdfasdf에서 분리)가 사라집니다.

예를 들어 분기 'dev'에서 커밋 asdfasd14314->를 체크 아웃하십시오.

'git checkout asdfasd14314'

당신은 지금 분리 된 머리 상태에 있습니다

'git branch'는 다음과 같은 것을 나열합니다->

* (detached from asdfasdf)
  dev
  prod
  stage

그러나 분리 된 헤드 상태에서 벗어나 dev로 돌아갑니다.

'git checkout dev'

그런 다음 'git branch'가 나열됩니다->

* dev
  prod
  stage

그러나 물론 분리 된 헤드 상태에서 변경 사항을 유지하지 않으려는 경우 변경을 시도하지 않고 이전 커밋을 보려고 많이 노력하고 있습니다.

Chris가 지적했듯이 다음과 같은 상황이있었습니다.

git symbolic-ref HEAD 실패 fatal: ref HEAD is not a symbolic ref

그러나 git rev-parse refs/heads/master복구 할 수있는 곳에서 좋은 커밋을 가리키고있었습니다 (제 경우에는 커밋을 사용하여 커밋을 볼 수 있습니다)git show [SHA]

그 후 많은 지저분한 일을했지만 해결 된 것처럼 보입니다.

git symbolic-ref HEAD refs/heads/master

그리고 머리가 다시 붙어 있습니다!

대신에 git checkout origin/master

그냥 해 git checkout master

그런 다음 git branch지점을 확인합니다.

오늘이 문제가 있었는데 하위 모듈을 업데이트했지만 지점에 없었습니다. 나는 이미 커밋 했으므로 스 태싱, 체크 아웃 및 스 태싱이 작동하지 않습니다. 나는 분리 된 머리의 커밋을 체리 피킹했습니다. 그래서 내가 저지른 직후 (푸시가 실패했을 때), 나는했다 :

git checkout master
git cherry-pick 99fe23ab

내 생각은 갔다 : 나는 분리 된 머리에 있지만 마스터가되고 싶습니다. 분리 된 상태가 마스터와 크게 다르지 않다고 가정하면 커밋을 마스터에 적용 할 수 있다면 설정됩니다. 바로 체리 픽이하는 일입니다.

마스터 위에서 커밋 을 하고 "뒤로 병합" master(즉 , master을 가리키고 자 함 HEAD) 하려는 경우 한 줄짜리는 다음과 같습니다.

git checkout -B master HEAD

1. master이미 존재하는 경우에도 라는 이름의 새 분기를 만듭니다 (이동하는 것과 같고 master원하는 것).
2. 새로 만든 지점이 현재 위치를 가리 키도록 설정되어 HEAD있습니다.
3. 새 지점이 체크 아웃되었으므로 master나중에 시작하십시오.

하위 리포지토리의 경우 특히 유용하지만 분리 된 상태에 자주 있습니다.

나는 같은 문제가 있었고 다음 단계를 통해 문제를 해결했습니다.

변경 사항을 유지해야하는 경우

1. 먼저 git checkout master마스터 브랜치로 돌아가려면 명령 을 실행해야합니다 .
2. 변경 사항을 유지해야 할 경우 바로 실행 git checkout -b changes하고 git checkout -B master changes

변경이 필요하지 않은 경우

1. 분기에서 추적되지 않은 파일을 모두 제거하려면 다음을 실행하십시오 git clean -df.

2. 그런 다음 리포지토리 내의 모든 비 단계적 변경 사항을 지워야합니다. 그렇게하려면git checkout --

3. 마지막으로 git checkout master명령 을 사용하여 브랜치를 마스터 브랜치로 되돌려 놓아야합니다 .

필자는 푸시하려는 로컬 커밋이 없으므로 로컬 브랜치를 다시 삭제하는 것만 큼 쉽습니다.

그래서 나는했다 :

git branch -d branchname

그런 다음 지점을 다시 확인하십시오.

git checkout branchname

내가없는 동안 master(예 : HEAD바로 위에 분리되어 master있고 그 사이에 커밋이없는) 일부 변경 사항이 있음을 알게 된 상황에서 개인적으로 자신을 발견하면 숨김이 도움이 될 수 있습니다.

git stash # HEAD has same content as master, but we are still not in master
git checkout master  # switch to master, okay because no changes and master
git stash apply  # apply changes we had between HEAD and master in the first place

간단히 말해 분리 된 HEAD 상태는 분기의 HEAD (또는 팁)에 체크 아웃되지 않았 음을 의미 합니다. .

예제 이해

대부분의 경우 브랜치는 다음과 같은 여러 커밋 순서입니다.

커밋 1 : 마스터-> 분기 _HEAD (123be6a76168aca712aea16076e971c23835f8ca)

커밋 2 : 마스터-> 123be6a76168aca712aea16076e971c23835f8ca-> branch_HEAD (100644a76168aca712aea16076e971c23835f8ca)

커밋 순서의 경우 위에서 볼 수 있듯이 분기는 최신 커밋을 가리 킵니다. 따라서이 경우 123be6a76168aca712aea16076e971c23835f8ca 커밋을 체크 아웃하면 지점의 HEAD가 100644a76168aca712aea16076e971c23835f8ca 를 가리키고 기술적으로 분기가없는 HEAD에서 체크 아웃 되므로 헤드 상태가 분리 됩니다. 따라서 분리 된 HEAD 상태에 있습니다.

이론적 설명

이 블로그에서는 Git 저장소가 커밋 트리이며 각 커밋 포인터가 업데이트 된 조상을 가리키는 각 커밋이 업데이트되고 각 브랜치에 대한 이러한 포인터가 .git / refs 하위 디렉토리에 저장되어 있음을 분명히 밝힙니다. 태그는 .git / refs / tags에 저장되고 브랜치는 .git / refs / heads에 저장됩니다. 파일을 살펴보면 각 태그가 40 자 커밋 해시가있는 단일 파일에 해당하며 @Chris Johnsen 및 @Yaroslav Nikitenko가 위에서 설명한 것처럼 이러한 참조를 확인할 수 있습니다.

나는 정말로 바보 같은 상태에 빠졌다. 다른 누군가가 이것을 유용하게 사용할 수 있을지 의심 스럽다.

git ls-remote origin
0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b        HEAD
6f96ad0f97ee832ee16007d865aac9af847c1ef6        refs/heads/HEAD
0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b        refs/heads/master

내가 결국 고쳐

git push origin :HEAD

이것은 나를 위해 완벽하게 작동했습니다.

1. git stash로컬 수정 사항 저장

변경 사항을 취소하려면
git clean -df
git checkout -- .
git clean은 추적되지 않은 모든 파일을 제거합니다 (경고 : .gitignore에서 직접 언급 된 무시 된 파일은 삭제하지 않지만 폴더에있는 무시 된 파일은 삭제 될 수 있음) .git checkout은 모든 스테이지되지 않은 변경 사항을 지 웁니다.

2. git checkout master메인 브랜치로 전환하기 (마스터를 사용한다고 가정)
3. git pull마스터 브랜치에서 마지막 커밋을 가져 오기
4. git status모든 것이 잘 보이는지 확인하십시오.

On branch master
Your branch is up-to-date with 'origin/master'.

내 경우에는을 실행 git status했으며 작업 디렉토리에 추적되지 않은 파일이 몇 개있는 것을 보았습니다.

리베이스 작업을 수행하려면 필요하지 않기 때문에 청소해야했습니다.

Eclipse에서 EGit 을 사용하는 경우 : 마스터가 주요 개발 지점이라고 가정하십시오.

• 지점, 일반적으로 새로운 지점으로 변경 사항을 커밋하십시오.
• 그런 다음 리모컨에서 당겨
• 프로젝트 노드를 마우스 오른쪽 버튼으로 클릭하고 팀을 선택한 다음 내역 표시를 선택하십시오.
• 그런 다음 마스터를 마우스 오른쪽 버튼으로 클릭하고 체크 아웃을 선택하십시오.
• 이클립스가 말하면, 하나의 로컬 하나의 원격 장치가있는 두 개의 마스터가 있습니다.

이 후 오리진 마스터에 다시 연결할 수 있어야합니다.

나는 같은 문제가 있었다. 나는 변경 사항을 숨기고 git stash로컬의 브랜치를 이전 커밋으로 재설정했다 git pull. git stash apply다시 변경하는 것을 잊지 마십시오.

git checkout checksum  # You could use this to peek previous checkpoints
git status # You will see HEAD detached at checksum
git checkout master # This moves HEAD to master branch