Devo mantenere i miei repository biforcati GitHub in giro per sempre?

L'eliminazione dei repository biforcati cancellerà la cronologia dalle richieste di pull.

L'eliminazionediunrepositorybiforcatocancelleràqualsiasiinformazioneassociataaltuorepository.Ciòpuòinfluireretroattivamentesuqualsiasiriferimentoalrepository,incluselerichiestedipullchesonogiàstateunite.(Vedi Richiesta pull mostra "repository sconosciuto" dopo la cancellazione del fork )

I tuoi commenti e commit dovrebbero essere conservati su eventuali richieste di pull associate al tuo repository, ma lo farai a tuo rischio.

Tuttavia, l'eliminazione di vecchi rami dopo un'unione è perfettamente sicura.

Mentre l'eliminazione dei repository dovrebbe essere evitata, l'eliminazione dei rami inutilizzati è perfettamente accettabile. Infatti, GitHub ti incoraggia a eliminare i vecchi rami .

Tidying up after Pull Requests

At GitHub, we love to use Pull Requests all day, every day. The only trouble is that we end up with a lot of defunct branches after Pull Requests have been merged or closed. From time to time, one of us would clear out these branches with a script, but we thought it would be better to take care of this step as part of our regular workflow on GitHub.com.

Starting today, after a Pull Request has been merged, you’ll see a button to delete the lingering branch:

If the Pull Request was closed without being merged, the button will look a little different to warn you about deleting unmerged commits:

Of course, you can only delete branches in repositories that you have push access to.

Enjoy your tidy repositories!

In alternativa, se davvero non vuoi tenerli in giro, puoi archiviare un repository per indicare che non è più mantenuto attivamente.

Vedi anche

• Blog GitHub: Riordinare dopo Pull Requests
• Blog GitHub: Eliminazione di un repository
• Guida GitHub: Eliminazione e ripristino di rami in una richiesta pull
• Problemi di GitHub: Richiesta di pull visualizza "repository sconosciuto" dopo la cancellazione del fork

Se la tua richiesta di pull è stata accettata e non hai apportato altre modifiche che potresti utilizzare personalmente, dovresti eliminarla.

1. L'eliminazione non danneggia nulla.
2. Puoi sempre reforker se hai bisogno di
3. Riduce i repository inutili nei risultati di ricerca quando le persone cercano qualcosa
4. Se usi il tuo GitHub come una specie di curriculum per potenziali lavori / contratti, sembra meglio se non hai dozzine di repository biforcati su cui non stai lavorando al momento. Sarai più efficiente.
5. Aiuta la tua sanità mentale quando non devi sfogliare centinaia di repository inutili.
6. È meglio per GitHub. :)

Puoi eliminare la tua forcella non appena presenti una richiesta di pull , indipendentemente dal fatto che sia unita o meno. GitHub memorizza tutti i PR nel repository upstream , il che significa che le modifiche proposte vengono tracciate anche se la forcella è stata cancellata.

Questo semplifica la decisione.

Puoi comunque mantenere il fork se:

• Contribuirai di più subito (ad esempio estendi PR già esistenti o apri nuovi PR)

Potresti voler eliminare il fork se:

• Vuoi un portafoglio di progetti pulito sotto il tuo nome

Probabilmente tar / gzip e inserirò una directory di archivio, quindi cancellarla 3 anni dopo. ;) Onestamente Se non hai intenzione di lavorarci di nuovo per i prossimi mesi e non l'ho usato da un po 'penso che sarebbe sicuro cancellarlo.

Solo per aggiungere le risposte fornite - GitHub raccomanda di eliminare ("riordinare") i repository biforcati dopo che sono stati uniti.

Questo può essere fatto direttamente nella richiesta pull dopo l'unione - per favore vedi questo post del blog .

Inoltre, a partire da questo momento, non vedo alcun aspetto negativo notato nei commenti:

• anche dopo aver eliminato il repository biforcato, c'è un messaggio corretto nella richiesta pull (nessun "repository sconosciuto")
Il repository
• a cui hai contribuito è ancora elencato nella tua attività di contribuzione
• sei ancora elencato nei contributori di quel repository

Non consiglierei di eliminarlo prima della fusione, come suggerito da @Dennis, poiché potresti dover apportare alcune modifiche al codice se richiesto dagli autori.