Je cherche des informations de base sur les commits et les blobs.
Mon référentiel semble correct. Mais j'ai exécuté git fsck pour la première fois pour voir ce qu'il a fait et j'ai une longue liste de 'dangling blobs' et un seul 'dangling commit'.
Que sont ces choses ? D'où viennent-elles ? Indiquent-ils quelque chose d'inhabituel (bon ou mauvais) concernant l'état de mon dépôt ?
Au cours de votre travail sur votre dépôt Git, vous pouvez être amené à effectuer des opérations en arrière, et faire d'autres mouvements qui provoquent des blobs intermédiaires, et même certaines choses que Git fait pour vous afin d'éviter la perte d'informations.
Éventuellement (sous condition, selon le page de manuel git gc ), il effectuera une collecte des déchets et nettoiera ces choses. Vous pouvez également le forcer en invoquant le processus de collecte des déchets, git gc .
Pour plus d'informations à ce sujet, voir Maintenance et récupération des données sur le site git-scm.
Une exécution manuelle de GC laissera par défaut deux semaines avant l'exécution de cette commande comme filet de sécurité. Il est en fait encouragé d'exécuter la GC occasionnellement pour aider à assurer une utilisation performante de votre dépôt Git. Comme toute chose, cependant, vous devez comprendre ce qu'elle fait avant de détruire les choses qui peuvent être importantes pour vous.
Une goutte d'eau \= Un changement qui est arrivé dans la zone de transit/index, mais qui n'a jamais été validé. Une chose qui est étonnante avec Git, c'est qu'une fois qu'elle a été ajoutée à la zone de transit, vous pouvez toujours la récupérer car ces blobs se comportent comme des commits en ce sens qu'ils ont aussi un hash !
Engagement en suspens \= Un commit qui n'est pas directement lié à un autre commit, une branche, un tag ou une autre référence. Vous pouvez aussi les récupérer !
COMMENT supprimer tous les commits en suspens de votre dépôt Git à partir de http://www.tekkie.ro/news/howto-remove-all-dangling-commits-from-your-git-repository/ :
git reflog expire --expire=now --all
git gc --prune=nowAssurez-vous que vous voulez vraiment les supprimer, car vous pourriez décider d'en avoir besoin après tout.
Un dangling commit est un commit qui n'est pas associé à une référence, c'est-à-dire qu'il n'y a aucun moyen de l'atteindre.
Par exemple, considérez le diagramme ci-dessous. Supposons que nous supprimions la branche featureX sans fusionner ses changements, alors le commit D deviendra un dangling commit parce qu'il n'y a pas de référence qui lui est associée. S'il avait été fusionné dans master, alors les références HEAD et master auraient pointé vers le commit D et il ne serait plus dangling, même si nous avons supprimé featureX. Lisez la note après le diagramme pour mieux comprendre cela.
Git fait automatiquement le garbage collector, c'est-à-dire qu'il se débarrasse des commits en suspens. Nous pouvons utiliser le git reflog pour récupérer une branche (de commits pendants) qui a été supprimée sans être fusionnée. Nous pouvons récupérer les commits supprimés seulement s'ils sont présents dans le magasin d'objets local. S'il a été collecté, alors nous ne pouvons pas le récupérer.
NOTE qu'un nom de branche, c'est-à-dire une étiquette de branche, est en fait une référence au dernier commit sur une branche ou à l'extrémité de la branche. Dans le diagramme ci-dessus, featureX, master et HEAD sont juste des références à des commits spécifiques. Les étiquettes featureX et master font référence aux derniers commits sur leurs branches respectives. HEAD fait généralement référence à l'extrémité de la branche actuellement extraite (master dans ce cas). Si vous extrayez un commit plus ancien sur votre branche actuelle, alors HEAD sera dans un état détaché, c'est-à-dire qu'il pointera vers le commit plus ancien au lieu du plus récent. Notez également que HEAD est appelé une référence symbolique parce qu'il pointe en fait vers l'étiquette de la branche actuelle et que toute étiquette de branche pointe toujours vers l'extrémité de la branche. Donc, dans des circonstances normales, HEAD pointe indirectement vers le dernier commit.
En passant, notez que Git représente son graphique/historique de commit sous la forme de graphe acyclique dirigé . Chaque commit a une référence à son parent. Par conséquent, les flèches dans un diagramme de commit pointent du commit enfant au commit parent. Nous avons besoin d'une référence au dernier commit enfant afin d'atteindre les commits plus anciens sur une branche.
PS - Le diagramme et la compréhension ci-dessus ont été obtenus à partir de ce cours gratuit . Même si le cours est assez ancien, les connaissances sont toujours pertinentes.
Un "dangling commit" se produit également si vous "modifiez" un commit. Par exemple, vous faites beaucoup de travail, le testez et commitez tous les fichiers, puis vous vous rappelez que vous avez oublié de mettre à jour le fichier README. Vous le modifiez donc rapidement, l'ajoutez, puis utilisez "git commit --amend". Cela crée un nouveau commit qui est lié à l'historique des commits, et le commit original est laissé en suspens.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
