"git push --mirror" è sufficiente per eseguire il backup del mio repository?

Question

Sono uno sviluppatore solista, che lavora in un repository Git locale. Per i backup, voglio inviare una copia esatta di quel repository su un altro server.

E 'sufficiente fare questo?

git push --mirror 

Mi sto chiedendo perché posso a volte eseguire questo comando due o tre volte prima di Git me "Tutto up-to-date" dice, così apparentemente non è uno specchio esatto. Sembra che si riesca a spingere i rami di rilevamento ...?

$ git push --mirror 
Counting objects: 42, done. 
Delta compression using up to 8 threads. 
Compressing objects: 100% (30/30), done. 
Writing objects: 100% (30/30), 5.09 KiB, done. 
Total 30 (delta 17), reused 0 (delta 0) 
To ssh://my/repo/url 
    c094a10..0eedc92 mybranch -> mybranch 
$ git push --mirror 
Total 0 (delta 0), reused 0 (delta 0) 
To ssh://my/repo/url 
    c094a10..0eedc92 origin/mybranch -> origin/mybranch 
$ git push --mirror 
Everything up-to-date 

Che cosa sta succedendo, ed è una buona strategia?

Modifica: non mi piace utilizzare qualcosa come gli archivi git bundle o .tar.bz2, perché mi piacerebbe che il backup fosse una copia di lavoro accessibile. Poiché il mio server di backup è connesso alla rete e sempre acceso, questo è un buon modo per accedere al repository quando sono in viaggio.

Answer 1

Direi che questa è una strategia perfettamente accettabile per il backup del repository. Dovrebbe eseguire una spinta al tuo telecomando di origine per ogni ref nel repository. Rendendolo un "mirror" completo del tuo repository locale.

EDIT: Ho appena visto la tua descrizione aggiornata nella domanda. Sembra che Git stia spingendo il tuo telecomando verso il remoto stesso insieme a tutto il resto. Una volta che la spinta è finita, il ref remoto verrà aggiornato per riflettere che ci hai appena spinto. Questo sarà ora obsoleto con il repository remoto, quindi è necessaria un'ulteriore spinta. Se questo non ti soddisfa. È possibile eliminare questo riferimento a distanza con

git push: origine/mybranch

e quindi utilizzare

git push --all

ricordare che questo ha vinto' Tuttavia, spinga qualsiasi nuovo ramo che crei.

Answer 2

Perché non comprimere semplicemente una copia della cartella .git e inviarla a un altro server?

Answer 3

Nello stesso spirito che Amber's answer, si potrebbe:

• spinta per un backup locale created with git bundle
• copiare il file unico al vostro server remoto.

Answer 4

Io di solito uso git push --all. Io uso solo --mirror quando ho bisogno di spingere rami appena creati o ho cancellato alcuni rami e non voglio nominarli uno per uno. Altrimenti il ​​push --all di solito funziona come ho bisogno.

Answer 5

La ragione per cui si vede una seconda volta spinta è che --mirror spinge un po 'più di quanto ci si aspetti. Oltre alle filiali locali, spinge anche le filiali remote, perché lo specchio implica tutto.Pertanto, quando si preme normalmente (o con --mirror), viene inviato mybranch e origin/mybranch viene aggiornato per riflettere il nuovo stato sull'origine. Quando si preme con --mirror, viene inviato anche origin/mybranch.

Ciò si traduce nella stranezza che si vede, e anche in una peggiore stranezza quando si tira da quel telecomando; si otterrebbero i rami denominati origin/origin/mybranch ecc. Di solito è preferibile utilizzare --mirror per le copie una tantum e utilizzare solo la normale pressione (forse con --all) per gli usi normali.

Per spingere sempre tutti i rami e tag, è possibile aggiornare .git/config in questo modo:

[remote "origin"] 
    url = ... 
    fetch = ... 
    push = +refs/heads/* 
    push = +refs/tags/* 

che farà una spinta normale simile a uno specchio, tranne che non cancellerà i rami che non esistono all'origine o per gli aggiornamenti non rapidi.

Answer 6

Sfortunatamente, non si ottiene una copia esatta con push. È lose your stash.

Answer 7

Quello che faccio è:

Setup repo: git clone --mirror user@server:/url-to-repo.git

Poi, quando si desidera aggiornare il backup: git remote update dalla posizione clone.

Questo esegue il backup di tutti i rami, inclusi i nuovi rami che vengono aggiunti in seguito, sebbene valga la pena notare che i rami che vengono eliminati non vengono eliminati dal clone (che per un backup può essere una buona cosa).

Da http://www.garron.me/en/bits/backup-git-bare-repo.html