Come posso riconciliare HEAD distaccato con master / origin?

Sono nuovo nelle complessità ramificate di Git. Lavoro sempre su un singolo ramo e commetto modifiche e quindi spingo periodicamente sulla mia origine remota.

Recentemente, da qualche parte, ho eseguito un ripristino di alcuni file per eliminarli dalla gestione temporanea del commit e in seguito ho rebase -ieliminato un paio di commit locali recenti. Ora sono in uno stato che non capisco bene.

Nella mia area di lavoro, git logmostra esattamente quello che mi aspetto-- Sono sul treno giusto con gli impegni che non volevo andare e quelli nuovi lì, ecc.

Ma ho appena spinto nel repository remoto, e cosa c'è di diverso - un paio dei commit che ho ucciso nel rebase sono stati spinti e quelli nuovi commessi localmente non ci sono.

Penso che "master / origin" sia separato da HEAD, ma non sono chiaro al 100% su cosa significhi, come visualizzarlo con gli strumenti da riga di comando e come risolverlo.

Innanzitutto, chiariamo cos'è HEAD e cosa significa quando è staccato.

HEAD è il nome simbolico per il commit attualmente estratto. Quando HEAD non è staccato (la situazione "normale" ¹ : hai un ramo estratto), HEAD in realtà punta al "ref" di un ramo e il ramo punta al commit. HEAD è quindi "attaccato" a un ramo. Quando si effettua un nuovo commit, il ramo a cui punta HEAD viene aggiornato per puntare al nuovo commit. HEAD segue automaticamente poiché punta semplicemente al ramo.

• git symbolic-ref HEADrese refs/heads/master
  La filiale denominata "master" viene estratta.
• git rev-parse refs/heads/masterrendimento 17a02998078923f2d62811326d130de991d1a95a
  Quel commit è l'attuale suggerimento o "capo" del ramo principale.
• git rev-parse HEADproduce anche 17a02998078923f2d62811326d130de991d1a95a
  Questo è ciò che significa essere un "riferimento simbolico". Indica un oggetto attraverso qualche altro riferimento.
  (I riferimenti simbolici sono stati originariamente implementati come collegamenti simbolici, ma in seguito sono stati modificati in file semplici con interpretazione aggiuntiva in modo da poter essere utilizzati su piattaforme che non dispongono di collegamenti simbolici.)

Abbiamo HEAD→ refs/heads/master→17a02998078923f2d62811326d130de991d1a95a

Quando HEAD è staccato, punta direttamente a un commit, anziché indirettamente verso uno attraverso un ramo. Puoi pensare a una HEAD distaccata come a un ramo senza nome.

• git symbolic-ref HEAD fallisce con fatal: ref HEAD is not a symbolic ref
• git rev-parse HEADrese 17a02998078923f2d62811326d130de991d1a95a
  Poiché non è un riferimento simbolico, deve puntare direttamente al commit stesso.

Abbiamo HEAD→17a02998078923f2d62811326d130de991d1a95a

La cosa importante da ricordare con un HEAD distaccato è che se il commit a cui punta è altrimenti non referenziato (nessun altro riferimento può raggiungerlo), allora diventerà "penzolante" quando si verifica un altro commit. Alla fine, tali commit sospesi saranno potati attraverso il processo di raccolta dei rifiuti (per impostazione predefinita, vengono conservati per almeno 2 settimane e possono essere conservati più a lungo facendo riferimento al reflog di HEAD).

¹ Va benissimo fare un lavoro "normale" con un HEAD distaccato, devi solo tenere traccia di ciò che stai facendo per evitare di dover eliminare la cronologia abbandonata dal reflog.

I passaggi intermedi di un rebase interattivo vengono eseguiti con una HEAD distaccata (parzialmente per evitare l'inquinamento del reflog del ramo attivo). Al termine dell'operazione di rebase completa, aggiornerà il ramo originale con il risultato cumulativo dell'operazione di rebase e ricollegherà HEAD al ramo originale. La mia ipotesi è che non hai mai completato completamente il processo di rebase; questo ti lascerà con un HEAD distaccato che punta al commit che è stato elaborato più di recente dall'operazione rebase.

Per ripristinare la situazione, è necessario creare un ramo che punti al commit attualmente indicato dal proprio HEAD distaccato:

git branch temp
git checkout temp

_{(questi due comandi possono essere abbreviati come git checkout -b temp)}

Ciò ricollegherà HEAD al nuovo tempramo.

Successivamente, dovresti confrontare l'attuale commit (e la sua cronologia) con il ramo normale su cui ti aspettavi di lavorare:

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

(Probabilmente vorrai sperimentare le opzioni di registro: aggiungi -p, lascia perdere --pretty=…per vedere l'intero messaggio di registro, ecc.)

Se il tuo nuovo tempramo ha un bell'aspetto, potresti voler aggiornare (ad es.) masterPer puntarlo:

git branch -f master temp
git checkout master

_{(questi due comandi possono essere abbreviati come git checkout -B master temp)}

È quindi possibile eliminare il ramo temporaneo:

git branch -d temp

Infine, probabilmente vorrai spingere la storia ristabilita:

git push origin master

Potrebbe essere necessario aggiungere --forcealla fine di questo comando per inviare se il ramo remoto non può essere "inoltrato rapidamente" al nuovo commit (ovvero è stato eliminato, riscritto un commit esistente o riscritto in qualche modo un po 'di cronologia).

Se ti trovassi nel mezzo di un'operazione di rebase, probabilmente dovresti ripulirla. È possibile verificare se era in corso un rebase cercando la directory .git/rebase-merge/. Puoi ripulire manualmente il rebase in corso semplicemente cancellando quella directory (ad esempio se non ricordi più lo scopo e il contesto dell'operazione di rebase attiva). Di solito useresti git rebase --abort, ma questo comporta un ulteriore ripristino che probabilmente vorrai evitare (riporta HEAD al ramo originale e lo ripristina al commit originale, che annullerà parte del lavoro che abbiamo fatto sopra).

Basta fare questo:

git checkout master

In alternativa, se hai delle modifiche che desideri conservare, procedi come segue:

git checkout -b temp
git checkout -B master temp

Ho riscontrato questo problema e quando ho letto nella risposta votata in alto:

HEAD è il nome simbolico per il commit attualmente estratto.

Ho pensato: Ah-ah! Se HEADè il nome simbolico per il commit di checkout corrente, posso riconciliarlo masterribadendolo contro master:

git rebase HEAD master

Questo comando:

1. controlla master
2. identifica i commit dei genitori di HEADritorno al punto HEADdivergente damaster
3. gioca in cima a questi commit master

Il risultato finale è che tutti i commit che erano in, HEADma non lo mastersono, anche in master. masterrimane controllato.

Per quanto riguarda il telecomando:

un paio dei commit che avevo ucciso nel rebase sono stati spinti e quelli nuovi commessi localmente non ci sono.

La cronologia remota non può più essere fatta avanzare rapidamente utilizzando la cronologia locale. Dovrai forzare la spinta (git push -f ) per sovrascrivere la cronologia remota. Se hai dei collaboratori, di solito ha senso coordinarli con loro in modo che tutti siano sulla stessa pagina.

Dopo aver effettuato il push mastersu remoto origin, il ramo di tracciamento remoto origin/masterverrà aggiornato per puntare allo stesso commit di master.

Guarda qui per la spiegazione di base della testa staccata:

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

Riga di comando per visualizzarlo:

git branch

o

git branch -a

otterrai un output come di seguito:

* (no branch)
master
branch1

Gli * (no branch)spettacoli sei in testa distaccata.

Avresti potuto venire in questo stato facendo un git checkout somecommitecc. E ti avrebbe avvertito di quanto segue:

Sei nello stato "HEAD distaccato". Puoi guardarti intorno, apportare modifiche sperimentali e impegnarle e puoi scartare qualsiasi commit che fai in questo stato senza influire su alcun ramo eseguendo un altro checkout.

Se si desidera creare un nuovo ramo per conservare i commit creati, è possibile farlo (ora o in seguito) usando nuovamente -b con il comando di checkout. Esempio:

git checkout -b new_branch_name

Ora, per farli diventare padroni:

Fai un git reflogo anche solo git loge nota i tuoi impegni. Ora git checkout mastere git mergegli impegni.

git merge HEAD@{1}

Modificare:

Per aggiungere, utilizzare git rebase -inon solo per eliminare / eliminare i commit non necessari, ma anche per modificarli. Basta menzionare "modifica" nell'elenco di commit e si sarà in grado di modificare il proprio commit e quindi emettere un git rebase --continueper andare avanti. Ciò avrebbe garantito che non sei mai entrato in una HEAD distaccata.

Ottieni il commit distaccato nel proprio ramo

Corri semplicemente git checkout -b mynewbranch.

Quindi esegui git loge vedrai che il commit è ora HEADsu questo nuovo ramo.

se hai appena un ramo master e vuoi tornare a "sviluppare" o una funzione, fai questo:

git checkout origin/develop

Nota: verifica origine / sviluppo .

Sei nello stato HEAD distaccato . Puoi guardarti intorno, apportare modifiche sperimentali e impegnarle, e puoi scartare qualsiasi commit che fai in questo stato senza influire su alcun ramo eseguendo un altro checkout ...

poi

git checkout -b develop

Funziona :)

Se vuoi spingere la tua HEAD attualmente staccata (controlla git logprima), prova:

git push origin HEAD:master

per inviare la TESTA staccata nel ramo principale all'origine. Se la tua spinta viene rifiutata, prova git pull origin masterprima a ottenere le modifiche dall'origine. Se non ti interessano le modifiche dall'origine ed è respinto, perché hai fatto un rebase intenzionale e vuoi sostituire origin / master con il tuo ramo attualmente staccato - allora puoi forzarlo ( -f). Nel caso in cui tu abbia perso l'accesso a precedenti commit, puoi sempre correre git reflogper vedere la cronologia di tutti i rami.

Per tornare su un ramo principale, mantenendo le modifiche, provare i seguenti comandi:

git rebase HEAD master
git checkout master

Vedi: Git: "Attualmente non in nessun ramo". C'è un modo semplice per tornare su un ramo, mantenendo le modifiche?

Ho trovato questa domanda durante la ricerca You are in 'detached HEAD' state.

Dopo aver analizzato ciò che avevo fatto per arrivare qui, rispetto a quello che avevo fatto in passato, ho scoperto di aver fatto un errore.

Il mio flusso normale è:

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

Questa volta ho fatto:

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

Il problema è che ho accidentalmente fatto:

git checkout origin/my-cool-branch

Piuttosto che:

git checkout my-cool-branch

La correzione (nella mia situazione) era semplicemente di eseguire il comando sopra e quindi continuare il flusso:

git checkout my-cool-branch
git pull

Quanto segue ha funzionato per me (utilizzando solo il master di filiale):

git push origin HEAD:master
git checkout master        
git pull

Il primo spinge la testa staccata verso l'origine remota.

Il secondo passa al branch master.

Il terzo recupera la TESTA che si attacca al branch master.

Al primo comando potrebbero sorgere problemi se il push viene rifiutato. Ma questo non sarebbe più un problema di testa staccata, ma riguarda il fatto che la testa staccata non è a conoscenza di alcune modifiche remote.

Ho appena incontrato questo problema oggi e sono abbastanza sicuro di averlo risolto facendo:

git branch temp
git checkout master
git merge temp

Ero sul mio computer di lavoro quando ho capito come farlo, e ora sto riscontrando lo stesso problema sul mio personal computer. Quindi dovrò aspettare fino a lunedì quando sarò di nuovo al computer di lavoro per vedere esattamente come l'ho fatto.

Se sei completamente sicuro che HEAD sia in buono stato:

git branch -f master HEAD
git checkout master

Probabilmente non puoi spingere verso l'origine, poiché il tuo padrone si è discostato dall'origine. Se sei sicuro che nessun altro sta usando il repository, puoi forzare:

git push -f

Molto utile se ci si trova in un ramo di funzionalità che nessun altro sta usando.

Tutto quello che devi fare è 'git checkout [nome-ramo]' dove [nome-ramo] è il nome del ramo originale da cui sei entrato in uno stato principale distaccato. Il (staccato da asdfasdf) scomparirà.

Quindi, ad esempio, nel ramo 'dev' si verifica il commit asdfasd14314 ->

'git checkout asdfasd14314'

ora sei in uno stato di testa distaccato

'git branch' elencherà qualcosa come ->

* (detached from asdfasdf)
  dev
  prod
  stage

ma per uscire dallo stato di testa staccato e tornare a dev ->

'git checkout dev'

e poi 'git branch' elencherà ->

* dev
  prod
  stage

ma questo ovviamente se non intendete mantenere alcun cambiamento dallo stato principale distaccato, ma mi ritrovo a farlo molto non con l'intenzione di apportare modifiche, ma solo di guardare un precedente commit

Come indicato da Chris, ho avuto la seguente situazione

git symbolic-ref HEAD fallisce con fatal: ref HEAD is not a symbolic ref

però git rev-parse refs/heads/master puntava a un buon commit da dove potevo recuperare (Nel mio caso l'ultimo commit e puoi vedere quel commit usandogit show [SHA]

Dopo ho fatto molte cose disordinate, ma quello che sembra aver risolto è solo

git symbolic-ref HEAD refs/heads/master

E la testa è di nuovo attaccata!

Invece di farlo git checkout origin/master

basta fare git checkout master

quindi git branchconfermerà la tua filiale.

Ho avuto questo problema oggi, dove avevo aggiornato un sottomodulo, ma non ero in alcun ramo. Mi ero già impegnato, quindi riporre, fare il checkout, non ripulirlo non avrebbe funzionato. Ho finito per scegliere la commessa del capo distaccato. Quindi, subito dopo essermi impegnato (quando la spinta falliva), ho fatto:

git checkout master
git cherry-pick 99fe23ab

Il mio pensiero è andato: sono su una testa distaccata, ma voglio essere un maestro. Supponendo che il mio stato distaccato non sia molto diverso dal master, se potessi applicare il mio commit al master, sarei impostato. Questo è esattamente ciò che Cherry-Pick fa.

Se hai eseguito alcuni commit in cima al master e vuoi solo "fonderti all'indietro" master(ovvero vuoi masterindicare HEAD), il one-liner sarebbe:

git checkout -B master HEAD

1. Questo crea un nuovo ramo chiamato master, anche se esiste già (che è come muoversi mastered è quello che vogliamo).
2. Il ramo appena creato è impostato per puntare a HEAD, che è dove sei.
3. Il nuovo ramo è stato estratto, quindi sei in masterseguito.

L'ho trovato particolarmente utile nel caso dei sottopository, che spesso si trovano in uno stato distaccato piuttosto spesso.

Ho avuto lo stesso problema e l'ho risolto seguendo i seguenti passaggi.

Se è necessario mantenere le modifiche

1. Per prima cosa devi eseguire il git checkout mastercomando per riportarti al ramo principale.
2. Se è necessario mantenere le modifiche appena eseguite git checkout -b changese git checkout -B master changes

Se non hai bisogno delle tue modifiche

1. Per rimuovere tutti i file non tracciati dalla corsa del ramo git clean -df.

2. Quindi è necessario cancellare tutte le modifiche non messe in scena all'interno del proprio repository. Per farlo devi correregit checkout --

3. Alla fine devi rimettere il tuo ramo nel ramo principale usando il git checkout mastercomando.

Per me è stato facile come cancellare di nuovo la filiale locale, dal momento che non avevo alcun commit locale che volevo spingere:

Così ho fatto:

git branch -d branchname

E quindi ricontrollare il ramo:

git checkout branchname

Quando mi trovo personalmente in una situazione in cui si scopre che ho apportato alcune modifiche mentre non ci sono master(cioè HEADè staccato proprio sopra la mastere non ci sono commit in mezzo) lo stash potrebbe aiutare:

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

In parole semplici, lo stato HEAD distaccato significa che non sei estratto su HEAD (o punta) di alcun ramo .

Comprendere con un esempio

Un ramo nella maggior parte dei casi è la sequenza di più commit come:

Commit 1: master -> branch_HEAD (123be6a76168aca712aea16076e971c23835f8ca)

Commit 2: master -> 123be6a76168aca712aea16076e971c23835f8ca -> branch_HEAD (100644a76168aca712aea16076e971c23835f8ca)

Come puoi vedere sopra in caso di sequenza di commit, la tua filiale punta al tuo ultimo commit. Quindi in quel caso se fai il checkout per eseguire il commit di 123be6a76168aca712aea16076e971c23835f8ca, allora saresti in stato di testa staccato poiché HEAD della tua filiale punta a 100644a76168aca712aea16076e971c23835f8ca e tecnicamente verrai verificato a HEAD di nessuna filiale. Quindi, sei nello stato HEAD distaccato.

Spiegazione teorica

In questo Blog si afferma chiaramente che un repository Git è un albero di commit, con ogni commit che punta al suo antenato con ogni puntatore di commit aggiornato e questi puntatori a ciascun ramo sono memorizzati nelle sottodirectory .git / refs. I tag sono memorizzati in .git / refs / tags e i rami sono memorizzati in .git / refs / head. Se guardi uno qualsiasi dei file, troverai che ogni tag corrisponde a un singolo file, con un hash di commit di 40 caratteri e come spiegato sopra da @Chris Johnsen e @Yaroslav Nikitenko, puoi dare un'occhiata a questi riferimenti.

Sono entrato in uno stato davvero sciocco, dubito che chiunque lo troverà utile ... ma per ogni evenienza

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

con cui alla fine ho risolto

git push origin :HEAD

Questo ha funzionato perfettamente per me:

1. git stashper salvare le modifiche locali

Se si desidera annullare le modifiche,
git clean -df
git checkout -- .
git clean rimuove tutti i file non monitorati (avviso: mentre non eliminerà i file ignorati menzionati direttamente in .gitignore, potrebbe eliminare i file ignorati che risiedono nelle cartelle) e git checkout cancella tutte le modifiche non organizzate.

2. git checkout masterper passare al ramo principale (Supponendo di voler usare il master)
3. git pullper estrarre l'ultimo commit dal ramo master
4. git statusper verificare che tutto appaia fantastico

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

Nel mio caso, ho corso git statuse ho visto che avevo alcuni file non tracciati nella mia directory di lavoro.

Per far funzionare il rebase, dovevo solo pulirli (poiché non ne avevo bisogno).

Se stai usando EGit in Eclipse: supponi che il tuo master sia il tuo ramo di sviluppo principale

• eseguire il commit delle modifiche a un ramo, normalmente uno nuovo
• quindi tirare dal telecomando
• quindi fai clic con il pulsante destro del mouse sul nodo del progetto, scegli team quindi scegli mostra cronologia
• quindi fai clic con il pulsante destro del mouse sul master, scegli check out
• se Eclipse te lo dice, ci sono due master uno locale uno remoto, scegli il telecomando

Dopodiché dovresti essere in grado di ricollegarti al master origin.

Ho avuto lo stesso problema. Ho nascosto le mie modifiche git stashe ripristinato duramente il ramo in locale a un precedente commit (pensavo che lo causasse), quindi ho fatto un git pulle non mi sto staccando quella testa ora. Non dimenticare git stash applydi avere nuovamente le modifiche.

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