2014-10-04 11 views
10

Sono molto nuovo per git e ho qualche domanda sulla conservazione. Se ho lavorato su un ramo ma non sono riuscito a raggiungere una posizione in cui posso commettere il ramo, la conservazione è la cosa giusta da usare. Le mie domande riguardanti la conservazione sono:Quanti/per quanto tempo vengono salvati da git?

  1. Quante barre vengono salvate?
  2. Per quanto tempo vengono salvate queste barre?
  3. Salvano temporaneamente il lavoro in modo che le modifiche vengano perse quando si riavvia il computer?

Se qualcuno potesse aiutarli rapidamente a chiarire questi sarebbe molto apprezzato.

+2

1. Quanti ne create. 2. Finché non si * rilascia *, * pop * o * clear * loro. 3. No; gli stash saranno ancora accessibili dopo un riavvio. Vedi http://git-scm.com/book/it/Git-Tools-Stashing – Jubobs

+0

Downvoter, la domanda potrebbe essere più sottile di quanto pensi ... – Jubobs

+1

In git non sei quasi mai in una posizione in cui non puoi commettere. Non trovo personalmente che lo stash sia così utile. –

risposta

15

1 - Quante barre vengono salvate?

Gli scomparti non appaiono dal nulla; solo se si creano loro, utilizzando

git stash 

o equivalentemente,

git stash save 

Quindi, quanti sono salvati? Tanti quanti ne crei.

2 - Per quanto tempo vengono salvate queste barre?

Questa domanda sembra innocente, ma la risposta è in realtà piuttosto sottile. Ci sono due aspetti da considerare qui: 1) il reflog dello stash e 2) il database degli oggetti del repository.

Quando si crea una scorta, Git

  • aggiunge una voce al reflog scorta,
  • crea due (tre se si utilizza il flag --include-untracked) commettere oggetti nel database del repository: quello che corrisponde alla il WIP (work in progress) nel tuo albero di lavoro, e un altro che corrisponde allo stato dell'area di staging (aka index).

Modifica: quegli oggetti di commit sono commit in buona fede, come può essere verificato eseguendo git cat-file -t su di essi. Semplicemente non sono raggiungibili da nessun ramo; vedi torek's comment.

Per impostazione predefinita, la garbage collection di Git elimina automaticamente le voci di reflog che hanno più di 90 giorni; è possibile specificare un diverso "vita" per le voci scorta reflog, eseguendo

git config gc.refs/stash.reflogexpire <lifetime> 

Altro che il meccanismo di garbage-collection sopra descritto, Git non cancellerà nascondigli di propria; una scorta rimarrà nel vostro repository locale (per almeno 90 giorni) fino a quando non si volontariamente

  • goccia, usando

    git drop <stash-reference> 
    

    che cancella la voce scorta specificato da il reflog di scorta;

  • ostacoli, utilizzando

    git pop <stash-reference> 
    

    cui si applica la scorta specificato e quindi elimina la voce corrispondente dal reflog scorta; o

  • corsa

    git stash clear 
    

che cancella tutte le voci del reflog scorta (attenzione con quella).

Tuttavia, tenere presente che queste tre azioni influiscono solo sul reflog di riserva. In particolare, non causano immediatamente l'eliminazione degli oggetti "WIP" e "index" associati dal database del repository; semplicemente rendono quegli oggetti irraggiungibili. Quest'ultimo rimarrà per un po 'in "repository limbo", fino a quando non sarà possibile ottenere la raccolta dei rifiuti e morire di "morte vera".

Questa è una cosa utile da sapere: se accidentalmente goccia una scorta, si potrebbe ancora essere in grado di recuperarlo dalle viscere della vostra repo, se si può ricordare o identificare lo SHAs dei suoi due oggetti (WIP e indice).

3 - Hanno appena memorizzare temporaneamente il lavoro in modo tale che le modifiche vengono perse quando si riavvia il computer?

N. Le barre non sono diverse da altri oggetti di commit; un riavvio non ha alcun effetto su di loro.

+3

Nota a margine: non sono solo "oggetti simili a commit", sono in effetti commit: sono solo commit che si trovano su * no * branch. Direi "crea due commit" piuttosto che "crea due oggetti di tipo commit". E, il ref di 'stash' ha uno speciale tempo di scadenza predefinito insolito di" mai ". – torek

+1

@torek Ho dovuto ricontrollare con 'git cat-file -t' ma hai ragione riguardo a quegli oggetti che si stanno commettendo. Tuttavia, dove nel documento è menzionato che il ref di 'stash' non scade? – Jubobs

+5

È documentato in modo scadente, forse non è affatto diverso dalle note di rilascio. In 'builtin/reflog.c' è questo bit, però:' if (! Strcmp (ref, "refs/stash")) {'con codice per impostare la scadenza su" mai "e il commento:" Se non configurato, fare in modo che lo stash non scada mai ". Non mi è del tutto chiaro quale sia il codice addizionale (non mostrato qui) all'interno del quale 'if' sta testando, prima di impostare la scadenza su" mai ". – torek

3

Le sequenze di git vengono salvate fino alla morte del disco rigido (diversamente dai commit, che di solito vengono trasmessi a un altro computer tramite git push, quindi sopravvivono a un guasto del disco rigido).

È possibile disporre di tutte le mosse che si desidera. Sbarazzati di quelli vecchi quando ne hai voglia eseguendo git stash drop o git stash clear (leggi i documenti per quelli).

Problemi correlati