Come risolvere il conflitto di git stash senza commit?

Come richiesto in questa domanda , voglio anche sapere come risolvere un conflitto git stash popsenza aggiungere tutte le modifiche a un commit (proprio come fa "git stash pop" senza un conflitto).

Il mio approccio attuale è molto freddo perché lo faccio in questo modo:

git stash pop -> CONFLICT
git stash drop
[resolve conflict]
[add conflict files]
git reset HEAD <all files that are in commit-mode>

[Aggiornamento] Un modo per riprodurlo:

mkdir foo; cd foo; git init
echo "1" > one
echo "2" > two
git add -A; git commit -m "first"
echo "1.1" > one
echo "2.1" > two
git stash
echo "2.2" > two
git commit -a -m "second"
echo "Only this file would stay in HEAD without the conflict" > third
git add third
git stash pop
git status

27/06/2016: Aggiunto un nuovo file chiamato 'terzo' all'esempio per mostrare che soluzioni alternative come la soluzione di scy funzionano solo per HEAD vuoti ma non risolvono il problema iniziale che HEAD non ha lo stesso contenuto come per un git stash popsenza conflitto.

Non seguire altre risposte

Bene, puoi seguirli :). Ma non penso che fare un commit e quindi reimpostare il ramo per rimuovere quel commit e soluzioni alternative simili suggerite in altre risposte sia il modo pulito per risolvere questo problema.

Soluzione pulita

La seguente soluzione sembra essere molto più pulita per me ed è anche suggerita dallo stesso Git : prova a eseguire git statusnel repository un conflitto:

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

Quindi facciamo ciò che Git suggerisce (senza fare inutili commit):

1. Manualmente (o usando alcuni strumenti di unione , vedi sotto) risolvi i conflitti.
2. Utilizzare git resetper contrassegnare i conflitti come risolti e annullare la messa in scena delle modifiche. Puoi eseguirlo senza parametri e Git rimuoverà tutto dall'indice. Non devi eseguire git addprima.
3. Infine, rimuovi la scorta con git stash drop, perché Git non lo fa in caso di conflitto.

Tradotto nella riga di comando:

$ git stash pop

# ...resolve conflict(s)

$ git reset

$ git stash drop

Spiegazione del comportamento predefinito

Esistono due modi per contrassegnare i conflitti come risolti: git adde git reset. Mentre git resetcontrassegna i conflitti come risolti e rimuove i file dall'indice, git addcontrassegna anche i conflitti come risolti, ma mantiene i file nell'indice.

L'aggiunta di file all'indice dopo la risoluzione di un conflitto è intenzionale. In questo modo è possibile differenziare le modifiche dalla scorta precedente e le modifiche apportate dopo la risoluzione del conflitto. Se non ti piace, puoi sempre utilizzare git resetper rimuovere tutto dall'indice.

Unisci strumenti

Consiglio vivamente di utilizzare uno qualsiasi degli strumenti di unione a 3 vie per risolvere i conflitti, ad esempio KDiff3 , Meld , ecc., Invece di farlo manualmente. Solitamente risolve automaticamente tutti o la maggior parte dei conflitti. È un enorme risparmio di tempo!

Supponiamo di avere questo scenario in cui riponi le modifiche per estrarre dall'origine. Forse perché le modifiche locali sono solo debug: truein alcuni file delle impostazioni. Ora tiri e qualcuno ha introdotto una nuova impostazione lì, creando un conflitto.

git status dice:

# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      src/js/globals.tpl.js
no changes added to commit (use "git add" and/or "git commit -a")

Va bene. Ho deciso di seguire ciò che Git ha suggerito: ho risolto il conflitto e mi sono impegnato:

vim src/js/globals.tpl.js
# type type type …
git commit -a -m WIP   # (short for "work in progress")

Ora la mia copia di lavoro è nello stato desiderato, ma ho creato un commit che non voglio avere. Come posso eliminare questo commit senza modificare la mia copia di lavoro? Aspetta, c'è un comando popolare per quello!

git reset HEAD^

La mia copia di lavoro non è stata modificata, ma il commit WIP è sparito. Questo è esattamente quello che volevo! (Nota che non sto usando --softqui, perché se ci sono file uniti automaticamente nella tua scorta, vengono messi in scena automaticamente e quindi finiresti con questi file di nuovo in scena dopo reset.)

Ma c'è ancora un'altra cosa: la pagina di git stash popmanuale ci ricorda che "L'applicazione dello stato può fallire con i conflitti; in questo caso, non viene rimosso dall'elenco di stash. È necessario risolvere i conflitti a mano e chiamare git stash dropmanualmente in seguito". Quindi è esattamente quello che facciamo ora:

git stash drop

E fatto.

Invece di aggiungere le modifiche apportate per risolvere il conflitto, è possibile utilizzare git reset HEAD fileper risolvere il conflitto senza mettere in scena le modifiche.

Tuttavia, potrebbe essere necessario eseguire questo comando due volte. Una volta per contrassegnare il conflitto come risolto e una volta per mettere in scena le modifiche messe in scena dalla routine di risoluzione del conflitto.

È possibile che ci sia una modalità di ripristino che fa entrambe queste cose contemporaneamente, sebbene non ce ne sia una adesso.

git checkout stash -- .

ha funzionato per me.

Nota : questo può essere pericoloso poiché non tenta di unire le modifiche dallo stash alla copia di lavoro, ma invece lo sovrascrive con i file stash . Quindi puoi perdere le modifiche senza commit.

git add .
git reset

git add . metterà in scena TUTTI i file dicendo a git che hai risolto il conflitto

git reset annullerà la messa in scena di TUTTI i file in scena senza creare un commit

Sembra che questa potrebbe essere la risposta che stai cercando, non l'ho ancora provata personalmente, ma sembra che potrebbe fare il trucco. Con questo comando GIT proverà ad applicare le modifiche come erano prima, senza provare ad aggiungerle tutte per il commit.

git stash apply --index

ecco la spiegazione completa:

http://git-scm.com/book/en/Git-Tools-Stashing

git stash branchwill works, che crea un nuovo ramo per te, verifica il commit che hai svolto quando hai nascosto il tuo lavoro, riapplica il tuo lavoro lì e quindi rilascia lo stash se si applica correttamente. controlla questo

Il modo più veloce che ho trovato è quello di risolvere il conflitto, quindi fare git add -u, e poi fare git reset HEAD, che non comporta nemmeno un commit.

Secondo le domande di git stash , dopo aver risolto il conflitto,git add <file> è la scelta giusta.

È stato dopo aver letto questo commento che ho capito che le modifiche vengono automaticamente aggiunte all'indice (in base alla progettazione). Ecco perché git add <file>completa il processo di risoluzione dei conflitti.

Non è il modo migliore per farlo ma funziona:

$ git stash apply
$ >> resolve your conflict <<
$ >> do what you want to do with your code <<
$ git checkout HEAD -- file/path/to/your/file