Devrais-je garder mon dépôt GitHub forked pour toujours?


314

J'ai donc modifié le référentiel de quelqu'un d'autre, apporté quelques modifications, soumis une demande d'extraction et mes modifications ont été intégrées au produit. Génial!

Mais ... que dois-je faire avec mon référentiel forké? Existe-t-il une raison impérieuse de conserver mon référentiel ou dois-je le supprimer et le supprimer? Je n'ai pas l'intention de faire de contributions supplémentaires, mais si je change d'idée, je suppose que je peux toujours la reformuler.

Je ne m'inquiète pas vraiment de garder une sauvegarde. Je m'inquiète davantage de rompre les liens, de perdre les messages de validation, etc.


80
Supprimez-le, sinon github manquera de hachages.
Armand

3
dupliquer le code est diabolique. Et cela va aussi au-delà des limites des git.
Départ

7
@stijn - Je lis ceci plus comme "sauvegarde" que "dupliquer". Et je ne pense pas avoir jamais entendu quelqu'un dire que le code de sauvegarde est diabolique ...
Beekguk

3
Supprime-le. Après tout, vous pouvez toujours télécharger le dernier état (celui dans lequel vous souhaitez continuer à travailler de toute façon) depuis le référentiel de projet.
Rook

Que se passe-t-il si le référentiel d'origine est supprimé et qu'il ne reste plus de fourches? Comment retrouver l'accès au repo / fork dans ce cas?
Kromster

Réponses:


40

La suppression de référentiels forkés effacera l'historique de vos demandes d'extraction.

PR avec référentiel inconnu

La suppression d'un référentiel créé supprimera toute information associée à votre référentiel. Cela peut affecter rétroactivement toutes les références à votre référentiel, y compris les demandes d'extraction déjà fusionnées. (Voir la requête Pull affiche "Repo inconnu" après la suppression du fork. )

Vos commentaires et vos commits doivent être conservés pour toutes les demandes d'extraction associées à votre référentiel, mais vous le ferez à vos risques et périls.

Cependant, la suppression d'anciennes branches après une fusion est parfaitement sûre.

Bien que la suppression de référentiels soit à éviter, la suppression de branches inutilisées est parfaitement acceptable. En fait, GitHub vous encourage à supprimer les anciennes branches .

Rangement après demandes de traction

Chez GitHub, nous aimons utiliser les demandes de tirage toute la journée, tous les jours. Le seul problème est que nous nous retrouvons avec un grand nombre de branches mortes après la fusion ou la fermeture des demandes d'extraction. De temps en temps, l'un de nous effaçait ces branches avec un script, mais nous pensions qu'il serait préférable de prendre en charge cette étape dans le cadre de notre processus de travail régulier sur GitHub.com.

Dès aujourd'hui, après la fusion d'une demande d'extraction, un bouton permettant de supprimer la branche en attente s'affiche:

Supprimer ce bouton de branche

Si la demande d'extraction a été fermée sans être fusionnée, le bouton sera un peu différent pour vous avertir de la suppression des commits non fusionnés:

Supprimer la branche avec avertissement

Bien entendu, vous ne pouvez supprimer que les branches des référentiels auxquels vous avez accès.

Profitez de vos dépôts bien rangés!

Sinon, si vous ne voulez vraiment pas les garder, vous pouvez archiver un référentiel pour indiquer qu'il n'est plus maintenu activement.

Voir également


1
Qu'advient-il exactement des demandes d'extraction fermée non fusionnées lorsque vous supprimez leur branche (le second cas de l'article cité)? Les commits seront-ils toujours disponibles dans la demande d'extraction, uniquement sans leur historique, ou seront-ils complètement partis?
Typo


207

Si votre demande de tirage a été acceptée et que vous n'avez apporté aucune modification que vous pourriez utiliser personnellement, vous devez la supprimer.

  1. La suppression ne nuit à rien.
  2. Vous pouvez toujours reforger si vous avez besoin de
  3. Il réduit le nombre de pensions inutiles dans les résultats de recherche lorsque les utilisateurs recherchent quelque chose.
  4. Si vous utilisez votre GitHub comme une sorte de curriculum vitae pour des travaux / contrats potentiels, il est préférable que vous n'ayez pas des dizaines de pensions sur lesquelles vous ne travaillez pas actuellement. Vous paraîtrez plus efficace.
  5. Cela aide votre santé mentale à ne pas parcourir des centaines de pensions inutilisables.
  6. C'est mieux pour GitHub. :)

50
Le seul inconvénient, c’est que la demande d’affichage indiquera alors «commit <commit> fusionné dans <repo>depuis unknown repositoryle <date>», ce qui est un peu étrange.
PLPeeters

18
@PLPeeters, En fait, c'est un très gros inconvénient.
Pacerier

4
Je suggère d'utiliser remove-github-forks"Supprimer tous les forks qui n'ont pas de commits qui ne sont pas dans le référentiel principal". Fonctionne comme un charme.
Fregante

3
@SteveMoser Je me trompe peut-être, mais je pense que vous conservez toujours la liste "Référentiels auxquels vous avez contribué". J'en ai eu une, j'ai enlevé chaque connexion entre elle et elle est toujours restée là, mais ça a peut-être été un coup de chance: P
Mark Pieszak - Trilon.io

17
J'ai pris le risque et supprimé le référentiel forké et ma liste de contributions n'a pas été affectée. Je peux donc affirmer en toute sécurité que la suppression du référentiel forké n'affectera pas vos crédits de contribution
Amin Mohamed Ajani

76

Vous pouvez supprimer votre fork dès que vous soumettez une demande d'extraction , qu'elle soit fusionnée ou non. GitHub stocke tous les PR dans le référentiel en amont , ce qui signifie que les modifications proposées sont suivies même si le fork est supprimé.

Cela simplifie la décision.

Vous voudrez peut-être quand même garder la fourchette si:

  • Vous contribuerez davantage immédiatement (par exemple, étendre les relations publiques existantes ou en ouvrir de nouvelles)

Vous voudrez peut-être supprimer le fork si:

  • Vous voulez un portefeuille propre de projets sous votre nom

7
"Vous pouvez supprimer votre fourche dès que vous envoyez votre demande Pull" C'est ce que je cherchais!
Unnawut

Moi aussi, mais la réponse commence par "Si votre demande de traction a été acceptée ..." L'avez-vous essayé: D
Legends

4
Avertissement : lorsque vous supprimez votre fork, le nom de la branche d'origine est supprimé de toutes les demandes d'extraction en attente. ( Stevoisiak veut fusionner 1 engagement dans Drugoy:masterdeunknown repository )
Stevoisiak

20

Je voudrais probablement tar / gzip et mettre dans un répertoire d'archive, puis le supprimer 3 ans plus tard. ;) Honnêtement, si vous n’avez pas l’intention de travailler dessus pendant quelques mois et que vous ne l’avez pas utilisé depuis un moment, je pense qu’il serait prudent de le supprimer.


9

Pour ajouter aux réponses fournies, GitHub lui-même recommande de supprimer ("ranger") les référentiels fourchus après leur fusion.

Cela peut être fait directement dans la demande d'extraction après la fusion - veuillez consulter ce billet de blog .

De plus, pour l'instant, je ne vois pas d'inconvénients dans les commentaires:

  • même après la suppression du référentiel forké, la demande d'extraction contient le message correct (pas de "référentiel inconnu")
  • le référentiel auquel vous avez contribué est toujours répertorié dans votre activité de contribution
  • vous êtes toujours listé dans les contributeurs de ce référentiel

Je ne recommanderais pas de le supprimer avant la fusion, comme suggéré par @Dennis, car vous devrez peut-être apporter quelques modifications au code si les auteurs le demandent.


2
Je viens de supprimer un référentiel forké et la demande d'extraction indique maintenant unknown repository. Tant pis.
Krassi

10
Votre lien mène à un article expliquant comment supprimer une branche après une fusion réussie de relations publiques; Cette question concerne toutefois la suppression d'un référentiel . Vous observerez le "référentiel inconnu" uniquement lorsque vous supprimez votre propre fork de projet ( référentiel ).
Stakx

2
La question concerne la suppression d'un fork et non d'une branche.
Andy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.