Qual è il caso d'uso previsto per git stash?

Se lavoro sul ramo A e improvvisamente ho bisogno di lavorare sul ramo B prima di essere pronto con un commit sul ramo A, metto le mie modifiche su A, eseguo il checkout B, faccio il mio lavoro lì, quindi checkout A e applico lo stash.

Se lavoro su A e voglio smettere di lavorare per la giornata, devo mettere da parte il mio lavoro e poi applicarlo il giorno successivo (quando riprendo a lavorare), o devo semplicemente lasciare le cose come sono: file modificati non salvati nella directory di lavoro? Non vedo perché avrei bisogno di usare stash in questo caso, tranne se c'è qualche vantaggio in termini di sicurezza.

Inoltre, un altro scenario: lavoro sia al lavoro che a casa. Se non sono pronto con un impegno quando voglio tornare a casa, posso mettere da parte il mio lavoro, inviarlo a GitHub e poi ritirarlo a casa?

Stash è solo un metodo conveniente. Poiché i rami sono così economici e facili da gestire in git, personalmente preferisco quasi sempre creare un nuovo ramo temporaneo piuttosto che riporre, ma è soprattutto una questione di gusti.

L'unico posto in cui mi piace riporre è se scopro di aver dimenticato qualcosa nel mio ultimo commit e ho già iniziato a lavorare su quello successivo nello stesso ramo:

# Assume the latest commit was already done
# start working on the next patch, and discovered I was missing something

# stash away the current mess I made
git stash save

# some changes in the working dir

# and now add them to the last commit:
git add -u
git commit --amend

# back to work!
git stash pop

Spezzerò la risposta su tre paragrafi.

Parte 1:

git stash(Per salvare le modifiche non salvate in una "scorta". Nota: questo rimuove le modifiche dall'albero di lavoro!)

git checkout some_branch(modifica al ramo previsto - in questo caso some_branch)

git stash list (elenca le scorte)

Puoi vedere:
stash @ {0}: WIP su {branch_name}: {SHA-1 of last commit} {last commit of you branch}
stash @ {0}: WIP on master: 085b095c6 modification for test

git stash apply (per applicare lo stash all'albero di lavoro nel ramo corrente)

git stash apply stash@{12}(se hai molte scorte puoi scegliere quale scorta verrà applicata - in questo caso applichiamo la scorta 12)

git stash drop stash@{0}(per rimuovere dalla lista delle scorte - in questo caso scorta 0)

git stash pop stash@{1} (per applicare la scorta selezionata e rilasciarla dall'elenco delle scorte)

Parte 2:
puoi nascondere le tue modifiche con questo comando ma non è necessario.
Puoi continuare il giorno successivo senza scorte.
Questi comandi per nascondere le tue modifiche e lavorare su diversi rami o per implementare qualche realizzazione del tuo codice e salvare in stash senza rami e salvare il tuo caso personalizzato!
E più tardi puoi usare alcune delle scorte e controllare quale è meglio.

Parte 3:
comando Stash per nascondere le modifiche in locale.
Se vuoi lavorare da remoto devi impegnarti e spingere.

L'idea principale è

Riponi le modifiche in una directory di lavoro sporca

Quindi il comando Basicallly Stash conserva alcune modifiche che non ti servono o che desideri al momento; ma potresti averne bisogno.

Usa git stash quando vuoi registrare lo stato corrente della directory di lavoro e dell'indice, ma vuoi tornare a una directory di lavoro pulita. Il comando salva le modifiche locali e ripristina la directory di lavoro in modo che corrisponda al commit HEAD .

Puoi usare i seguenti comandi:

• Per salvare le modifiche non salvate

  git stash

• Per elencare le tue scorte salvate

  git stash list

• Per applicare / recuperare le modifiche non registrate dove x è 0,1,2 ...

  git stash apply stash@{x}

Nota:

• Per applicare una scorta e rimuoverla dall'elenco delle scorte

  git stash pop stash@{x}

• Per applicare una scorta e tenerla nell'elenco delle scorte

  git stash apply stash@{x}

Se premi git stashquando hai modifiche nella copia di lavoro (non nell'area di staging), git creerà un oggetto nascosto e lo inserirà nella pila di scorte (proprio come hai fatto git checkout -- .ma non perderai le modifiche). Successivamente, puoi saltare dalla cima della pila.

Il comando stash memorizzerà tutte le modifiche apportate dall'ultimo commit. Nel tuo caso non c'è motivo di metterti da parte se continuerai a lavorarci il giorno successivo. Userei solo stash per annullare le modifiche che non desideri eseguire.

So che StackOverflow non è il posto giusto per risposte basate sull'opinione, ma in realtà ho una buona opinione su quando accantonare le modifiche con una scorta.

Non vuoi eseguire modifiche sperimentali

Quando si apportano modifiche al proprio spazio di lavoro / albero di lavoro, se è necessario eseguire operazioni basate su rami come unione, push, fetch o pull, è necessario essere a un punto di commit pulito. Quindi, se hai modifiche allo spazio di lavoro, devi eseguirne il commit. Ma cosa succede se non vuoi impegnarli? E se fossero sperimentali? Qualcosa che non vuoi far parte della tua cronologia dei commit? Qualcosa che non vuoi che gli altri vedano quando esegui il push su GitHub?

Non vuoi perdere le modifiche locali con un hard reset

In tal caso, puoi eseguire un hard reset. Ma se esegui un hard reset perderai tutte le modifiche dell'albero di lavoro locale perché tutto viene sovrascritto al punto in cui si trovava al momento dell'ultimo commit e perderai tutte le modifiche.

Quindi, per quanto riguarda la risposta di 'quando dovresti stash', la risposta è quando devi tornare a un punto di commit pulito con un albero di lavoro / indice / commit sincronizzato, ma non vuoi perdere le modifiche locali in il processo. Accantona le tue modifiche in una scorta e sei a posto.

E una volta che hai fatto la tua scorta e poi unito o tirato o spinto, puoi semplicemente mettere da parte pop o applicare e sei tornato da dove hai iniziato.

Git stash e GitHub

GitHub aggiunge costantemente nuove funzionalità, ma al momento c'è un modo per salvare una scorta lì. Ancora una volta, l'idea di una scorta è che sia locale e privata. Nessun altro può sbirciare nella tua scorta senza accesso fisico alla tua workstation. Un po 'allo stesso modo in cui git reflog è privato con git log è pubblico. Probabilmente non sarebbe privato se fosse inviato a GitHub.

Un trucco potrebbe essere quello di fare un diff del tuo spazio di lavoro, controllare il diff nel tuo repository git, eseguire il commit e poi spingere. Quindi puoi fare un tiro da casa, ottenere il diff e poi rilassarlo. Ma questo è un modo piuttosto complicato per ottenere quei risultati.

git diff > git-dif-file.diff