Come posso archiviare i rami git?

Ho alcuni vecchi rami nel mio repository git che non sono più in fase di sviluppo attivo. Vorrei archiviare i rami in modo che non vengano visualizzati per impostazione predefinita durante l'esecuzionegit branch -l -r . Non voglio eliminarli, perché voglio conservare la cronologia. Come posso fare questo?

So che è possibile creare un riferimento al di fuori di riferimenti / teste. Ad esempio refs/archive/old_branch,. Ci sono delle conseguenze nel farlo?

Credo che il modo corretto per farlo sia etichettare il ramo. Se elimini il ramo dopo averlo taggato, hai effettivamente tenuto il ramo intorno ma non ingombrerà l'elenco dei rami.

Se devi tornare alla filiale, dai un'occhiata al tag. Ripristinerà efficacemente il ramo dal tag.

Per archiviare ed eliminare il ramo:

git tag archive/<branchname> <branchname>
git branch -d <branchname>

Per ripristinare il ramo qualche tempo dopo:

git checkout -b <branchname> archive/<branchname>

La storia del ramo verrà preservata esattamente come quando l'hai taggata.

La risposta di Jeremy è corretta in linea di principio, ma IMHO i comandi che specifica non sono del tutto giusti.

Ecco come archiviare un ramo in un tag senza dover effettuare il checkout del ramo (e, quindi, senza dover effettuare il checkout in un altro ramo prima di poter eliminare quel ramo):

> git tag archive/<branchname> <branchname>
> git branch -D <branchname>

Ed ecco come ripristinare un ramo:

> git checkout -b <branchname> archive/<branchname>

Sì, è possibile creare un riferimento con un prefisso non standard utilizzando git update-ref. per esempio

• Archivia il ramo: git update-ref refs/archive/old-topic topic && git branch -D topic
• Ripristina il ramo (se necessario): git branch topic refs/archive/old-topic

I riferimenti con prefisso non standard (qui refs/archive) non verranno visualizzati come al solito git branch, git logné git tag. Tuttavia, puoi elencarli con git for-each-ref.

Sto usando i seguenti alias:

[alias]
    add-archive = "!git update-ref refs/archive/$(date '+%Y%m%d-%s')"
    list-archive = for-each-ref --sort=-authordate --format='%(refname) %(objectname:short) %(contents:subject)' refs/archive/
    rem = !git add-archive
    lsrem = !git list-archive

Inoltre, potresti voler configurare telecomandi come push = +refs/archive/*:refs/archive/*spingere i rami archiviati automaticamente (o git push origin refs/archive/*:refs/archive/*per uno scatto).

Un altro modo è scrivere SHA1 da qualche parte prima di eliminare il ramo, ma ha dei limiti. Gli impegni senza alcun riferimento verranno eseguiti dopo 3 mesi (o un paio di settimane senza reflog) , per non parlare del manuale git gc --prune. Gli commit indicati dagli ref sono al sicuro da GC.

Modifica: trovata un'implementazione perl della stessa idea di @ap :git-attic

Modifica ^ 2: trovato un post sul blog in cui Gitster stesso utilizza la stessa tecnica.

Ho fatto l' estensione della risposta di Steve per riflettere le modifiche sul telecomando

 git tag archive/<branchname> <branchname>
 git branch -D <branchname>
 git branch -d -r origin/<branchname>
 git push --tags
 git push origin :<branchname>

Per ripristinare dal telecomando, vedere questa domanda .

È possibile archiviare i rami in un altro repository. Non altrettanto elegante, ma direi che è una valida alternativa.

git push git://yourthing.com/myproject-archive-branches.git yourbranch
git branch -d yourbranch

Ecco un alias per questo:

arc    = "! f() { git tag archive/$1 $1 && git branch -D $1;}; f"

Aggiungilo così:

git config --global alias.arc '! f() { git tag archive/$1 $1 && git branch -D $1;}; f'

Tieni presente che esiste git archivegià un comando, quindi non puoi usarlo archivecome nome alias.

Inoltre è possibile definire un alias per visualizzare l'elenco dei rami 'archiviati':

arcl   = "! f() { git tag | grep '^archive/';}; f"

sull'aggiunta di alias

Sto usando i seguenti alias per nascondere i rami archiviati:

[alias]
    br = branch --no-merge master # show only branches not merged into master
    bra = branch                  # show all branches

Quindi git brper mostrare rami sviluppati attivamente e git braper mostrare tutti i rami compresi quelli "archiviati" .

Non archiverei i rami. In altre parole, i rami si archiviano da soli. Quello che vuoi è garantire che le informazioni rilevanti per gli archeologi possano essere trovate con mezzi affidabili. Affidabili in quanto aiutano lo sviluppo quotidiano e non aggiungono un ulteriore passo al processo di completamento del lavoro. Cioè, non credo che la gente ricorderà di aggiungere un tag una volta che hanno finito con un ramo.

Ecco due semplici passaggi che aiuteranno notevolmente l'archeologia e lo sviluppo.

1. Collega ogni ramo di attività a un problema associato nel tracker problemi utilizzando una semplice convenzione di denominazione .
2. Utilizzare sempre git merge --no-ffper unire i rami delle attività; vuoi che unisci il commit e la bolla della cronologia, anche per un solo commit.

Questo è tutto. Perché? Perché come archeologo di codice, raramente inizio con la voglia di sapere che lavoro è stato fatto su una filiale. Molto più spesso è il motivo per cui in tutti i nove inferni urlanti è il codice scritto in questo modo ?!Devo cambiare il codice, ma ha alcune caratteristiche strane e devo risolverle per evitare di rompere qualcosa di importante.

Il prossimo passo è git blame trovare i commit associati e quindi sperare che il messaggio di log sia esplicativo. Se ho bisogno di scavare più a fondo, scoprirò se il lavoro è stato svolto in un ramo e leggerò il ramo nel suo insieme (insieme al suo commento nel tracker dei problemi).

Diciamo git blamepunti su commit XYZ. Apro un browser della cronologia di Git (gitk, GitX git log --decorate --graph, ecc ...), trovo commit XYZ e vedo ...

AA - BB - CC - DD - EE - FF - GG - II ...
     \                       /
      QQ - UU - XYZ - JJ - MM

C'è il mio ramo! So che QQ, UU, XYZ, JJ e MM fanno tutti parte dello stesso ramo e dovrei guardare i loro messaggi di registro per i dettagli. So che GG sarà un commit di unione e avrà il nome del ramo che si spera sia associato a un problema nel tracker.

Se, per qualche motivo, voglio trovare un vecchio ramo, posso eseguirlo git loge cercare il nome del ramo nel commit di unione. È abbastanza veloce anche su repository molto grandi.

Questo è ciò che intendo quando dico che i rami si archiviano da soli.

La codifica di ogni ramo aggiunge un lavoro inutile per portare a termine le cose (un processo critico che dovrebbe essere spietatamente semplificato), eleva la lista dei tag (non parlando di prestazioni, ma leggibilità umana) con centinaia di tag che sono solo occasionalmente utili, e non è è anche molto utile per l'archeologia.

Il mio approccio è quello di rinominare tutti i rami che non mi interessano con un prefisso "trash_", quindi utilizzare:

git branch | grep -v trash

(con un'associazione chiave shell)

Per conservare la colorazione del ramo attivo, è necessario:

git branch --color=always | grep --color=never --invert-match trash

Puoi usare uno script che archivierà il ramo per te

archbranch

Crea un tag per te con l'archivio prefisso / e quindi elimina il ramo. Ma controlla il codice prima di usarlo.

Utilizzo - $/your/location/of/script/archbranch [branchname] [defaultbranch]

Se vuoi eseguire lo script senza scrivere la posizione in esso aggiungilo al tuo percorso

Quindi puoi chiamarlo da

$ archbranch [branchname] [defaultbranch]

Il [defaultbranch]è il ramo che si andrà a quando l'archiviazione è fatto. Ci sono alcuni problemi con la codifica a colori, ma altri che dovrebbero funzionare. Lo uso da tempo nei progetti, ma è ancora in fase di sviluppo.

A volte archivio i rami come segue:

1. Genera file patch, ad es. format-patch <branchName> <firstHash>^..<lastHash>(Ottieni firstHash e lastHash usando git log <branchName>.
2. Spostare i file patch generati nella directory su un file server.
3. Elimina il ramo, ad es. git branch -D <branchName>

"Applica" la patch quando è necessario utilizzare nuovamente il ramo; tuttavia, l'applicazione dei file patch (vedi git am) può essere impegnativa a seconda dello stato del ramo di destinazione. Tra i lati positivi, questo approccio ha il vantaggio di consentire la raccolta dei rifiuti della filiale e di risparmiare spazio nel repository.