2013-02-14 16 views
6

Mi piace rimuovere i repository su cui non sto lavorando dal mio computer. Controllo qualcosa, ci lavoro e quando ho finito spingo tutto ed elimina la cartella dal mio computer. In questo modo le cose restano in ordine, è facile avere una visione d'insieme su cosa sto effettivamente lavorando e so che non ho alcun materiale locale in attesa di essere spinto.Come assicurarsi che tutto sia stato spinto con git?

Ma ...

Prima di eliminare il mio repo locale che voglio per assicurarsi che tutto è stato spinto al mio telecomando. Il processo che passo è in genere questi tre passaggi:

git st # check if there's something I haven't committed 

git stash list # check if I've stashed something 

git log --oneline --decorate --all # check if all branches have been pushed 

Vorrei semplificarlo. Soprattutto l'ultimo passaggio, che richiede di guardare tutte le mie filiali e vedere se sono sincronizzati quelli locali e quelli remoti. Per essere davvero sicuro, potrei anche dover scorrere un po 'per assicurarmi che non mi manchi nulla.

Sto pensando di scrivere una sceneggiatura per fare tutto questo automaticamente, ma forse c'è già una soluzione là fuori? (Lo prendo Non devo sottolineare che voglio questo fatto sulla riga di comando e non usando alcuna GUI di fantasia: D)

Come vi avvicinate questo? Qual è il tuo processo per verificare che non stai dimenticando nulla? quali strumenti usi? Tutte le idee sono ben accette!

risposta

5

Per sapere se una filiale locale e una remota sono sincronizzate è necessario confrontare gli hash delle revisioni HEAD.

Quando si esegue git branch -v -a riceverete un elenco di sedi locali e remoti con gli hash delle revisioni HEAD corrispondenti:

$ git branch -v -a 
    develop        44e61b5 <Commit message> 
    feature/CodeContracts    c26edee <Commit message> 
* feature/Foo       3a40e22 <Commit message> 
    master        e68e28a <Commit message> 
    remotes/origin/HEAD     -> origin/master 
    remotes/origin/develop    44e61b5 <Commit message> 
    remotes/origin/feature/Bar   be9666c <Commit message> 
    remotes/origin/master    e68e28a <Commit message> 

Come si può facilmente vedere, sviluppare e maestro sono up-to-date locale e remoto, feature/Bar non esiste localmente e feature/CodeContracts e feature/Foo non esistono in remoto, quindi devono essere spinti prima di eliminare il repository locale.

+0

Ancora meglio: utilizzare "git branch -vva" (nota double-v). Questo stamperà anche il ramo upstream in cui è stato impostato uno, rendendolo ovvio se qualcosa non è stato premuto. In questo modo, il confronto degli SHA1s sarà necessario solo per le filiali locali senza un ramo a monte. – sleske

+0

@sleske: ho scoperto che è fuorviante. Stampa un ramo remoto inesistente per il ramo di funzione 'Foo'. –

+0

Sarebbe bello se il downvoter potesse lasciare un commento. Altrimenti non posso aggiustare la risposta. –

1

L'eliminazione ripetuta dei repos è una cosa brutta. Il repository Linux ad esempio è 126 MB; puoi vedere come potrebbe diventare vecchio velocemente. Forse this script sarebbe di aiuto. Controlla tutte le cartelle in una directory (in questo caso /opt) e fornisce lo git status di ognuna.

#!/bin/sh 
warn() 
{ 
    printf '\e[1;35m%s\e[m\n' "$*" 
} 
c() 
{ 
    printf '\ec' 
} 
compgen -d /opt/ | while read k 
do 
    c 
    cd $k 
    git status 
    warn $k 
    read </dev/tty 
done 
+1

Mi piacerebbe sentire una risposta più elaborata sul perché eliminare i repository locali è male. Mi aspettavo che qualcuno lo dicesse, quindi ora mi chiedo perché :) Il repository di Linux è un pessimo esempio, la maggior parte del mio codice è suddiviso in biblioteche e quindi di dimensioni più piccole. Ho creato circa 50 repository pubblici su GitHub e ne ho forse anche due dozzine private. La maggior parte di loro non è stata cambiata di recente, quindi personalmente non ho alcun interesse a tenerli tutti sul mio disco tutto il tempo. Ma sono tutte orecchie per capire perché questa pratica è cattiva. – Jakob

3

Sulla risposta di Daniel Hilgarth, mi consiglia le seguenti operazioni

In primo luogo, eseguire git fetch --all per assicurarsi di avere le ultime modifiche da tutti i repository upstream

quindi eseguire git branch -vva - (nota il doppio -v). Questo stamperà tutti i rami (a), e per ogni ramo l'ultimo commit e le informazioni sul ramo upstream (se è impostato un upstream).

Il risultato sarà simile a questa:

br1     88006cd Branch 
    br2     0b68b6f [origin/br2] New commit 
    c      9ed6569 Dummy 
* master    f4664d4 [origin/master: ahead 1] my commit 
    remotes/origin/HEAD -> origin/master 
    remotes/origin/br3 9ed6569 Dummy 
    remotes/origin/master 9ed6569 Dummy 

Si può vedere di avere quattro sedi locali (master, c, BR1, BR2). master e br2 hanno filiali upstream. br2 è completamente inserito, il master ha un commit locale che non è ancora stato premuto ("ahead 1").

br1 ec sono filiali locali senza informazioni a monte. Per questi è necessario controllare e decidere cosa fare: possono essere completamente uniti e ridondanti; o potresti volerli spingere a monte; o potresti voler unirli localmente, ad es. padroneggiare e poi spingerlo. Per vedere i rami che non sono completamente integrati nel tuo master locale, usa git branch --no-merged master. In questo esempio, questo stamperebbe "br1 br2" (perché il ramo c è un antenato del master).

Infine, è possibile vedere che per br2 è elencato l'origine del ramo upstream/br2, che non esiste. Ciò significa che il repository remoto ha eliminato questo ramo (e hai recuperato questa eliminazione usando "git remote prune" o "git fetch -p"). Di nuovo, devi decidere se vuoi scartare i tuoi commit locali, o reinserirli o unirli.

+0

+1: "ahead 1" è bello. –

Problemi correlati