Che cos’è questo messaggio di avviso Git quando si inseriscono le modifiche in un repository remoto?

La descrizione è un po ‘concisa. Ho semplicemente aggiunto un file sul mio ramo master locale e reindirizzato a un repository remoto. Qualche idea sul perché sta arrivando?

 avviso: aggiornamento dell'attuale avviso di diramazione: l'aggiornamento del ramo attualmente estratto può causare confusione, avviso: poiché l'indice e l'albero di lavoro non riflettono le modifiche presenti in HEAD.  avviso: di conseguenza, potresti visualizzare le modifiche appena inserite nell'avvertimento: ripristinato quando esegui "git diff" e potresti voler avvertire: per eseguire "git reset --hard" prima di iniziare a lavorare per recuperare .  warning: warning: è ansible impostare la variabile di configurazione 'receive.denyCurrentBranch' in warning: 'reject' nel repository remoto per vietare di inserire il suo avviso: ramo corrente.  warning: per consentire di spingere nel ramo corrente, puoi impostarlo su 'ignore';  avviso: ma questo non è raccomandato a meno che non si sia disposto ad aggiornare il proprio avviso di lavoro: albero per abbinare ciò che si è spinto in qualche altro modo.  warning: warning: per silenziare questo messaggio, puoi impostarlo su "warn".  warning: warning: si noti che l'impostazione predefinita cambierà in una versione futura di git warning: rifiutare di aggiornare il ramo corrente a meno che non si disponga dell'avviso: la variabile di configurazione è impostata su "ignora" o "warn". 

In realtà, significa praticamente esattamente quello che dice: qualcuno sta lavorando nel repository a cui stai spingendo, e che qualcuno ha attualmente controllato lo stesso ramo in cui stai spingendo.

Questo è molto confuso, perché ora pensa di aver controllato l’ultima versione del ramo, quando, infatti, hai appena aggiornato il ramo con una versione più recente. Quindi, quando ora esegue git commit , il suo commit essenzialmente ripristinerà tutti i commit che hai appena spinto. E quando esegue git diff , vedrà il contrario di tutto ciò che hai appena spinto, anche se forse non ha nemmeno cambiato nulla.

Per questo motivo, è generalmente considerato una ctriggers pratica spingere verso un repository non nudo; dovresti solo spingere a scoprire i repository, cioè i repository che non hanno una copia di lavoro allegata. Per lo meno dovresti assicurarti di non spingere verso il ramo attualmente ritirato, ma in generale non dovresti semplicemente spingere il tuo codice nel repository di qualcun altro, dovresti chiedere loro di ritirarti da te.

In alcuni casi speciali, come quando si sta servendo un sito Web da un repository Git e si desidera aggiornare il sito Web spingendolo, è logico passare al ramo attualmente estratto, ma in tal caso è necessario assicurarsi che hai installato un hook che aggiorna effettivamente la copia di lavoro ritirata, altrimenti il ​​tuo sito web non verrà mai aggiornato.

Se nessuno sta lavorando in quel repository remoto non nudo, dovrebbe essere ansible passare a un ramo estratto.

Ma per essere più sicuri in questa operazione, ora puoi (con Git 2.3.0, febbraio 2015) fare in quel repository remoto:

 git config receive.denyCurrentBranch updateInstead 

È più sicuro di config receive.denyCurrentBranch=ignore : consentirà il push solo se non stai sovrascrivendo le modifiche in corso.

Vedi commit 1404bcb di Johannes Schindelin ( dscho ) :

receive-pack : aggiungi un’altra opzione per receive.denyCurrentBranch

Quando si sincronizza tra le directory di lavoro, può essere utile aggiornare il ramo corrente tramite ” push ” anziché ” pull “, ad esempio quando si spinge una correzione dall’interno di una VM o quando si spinge una correzione effettuata sulla macchina di un utente (dove lo sviluppatore è non è libero di installare un demone ssh e tanto meno conoscere la password dell’utente).

La soluzione alternativa comune: l’inserimento di un ramo temporaneo e l’unione sull’altro computer non sono più necessari con questa patch.

La nuova opzione è:

 updateInstead 

Aggiorna l’albero di lavoro di conseguenza, ma rifiuta di farlo se ci sono delle modifiche non impegnate.


Il commit 4d7a5ce aggiunge più test e menziona:

Il precedente verifica solo il caso in cui un percorso che deve essere aggiornato dal push-to-deploy ha una modifica incompatibile nell’albero di lavoro del target che è già stato aggiunto all’indice, ma la funzionalità stessa richiede di richiedere l’albero di lavoro molto più pulito di quello testato

Aggiungere una manciata di ulteriori test per proteggere la funzionalità da future modifiche che erroneamente (dal punto di vista dell’inventore della funzionalità) allenta i requisiti di pulizia, ovvero:

  • Un cambiamento solo per l’albero di lavoro ma non per l’indice è ancora una modifica da proteggere;
  • Un file non tracciato nell’albero di lavoro che verrebbe sovrascritto da un push-to-deploy deve essere protetto;
  • Un cambiamento che accade per rendere un file identico a quello che viene spinto è ancora un cambiamento da proteggere (cioè il requisito di pulizia della funzione è più severo di quello del checkout).

Inoltre, verifica che una modifica solo stat alla struttura di lavoro non sia un motivo per rifiutare un push-to-deploy.

Questo è lo stesso problema di Questa domanda , la soluzione è usare git init --bare o git clone --bare .