Tout en travaillant sur GIT, les développeurs clonaient les référentiels distants afin qu'ils puissent accéder aux fichiers du projet et apporter leurs modifications. Plus précisément, le clonage crée une copie locale d'un référentiel distant sur le système local de l'utilisateur et leur permet de travailler sur le projet localement. Après cela, ils peuvent repousser leurs modifications locales dans le référentiel Github pour que les autres membres de l'équipe puissent accéder.
Cet article expliquera:
Est-il sûr de faire en sorte que le repo Git Clone / Copie avec «-depth 1», faites des commits et obtenez / tirez à nouveau les mises à jour?
Il est généralement sûr de cloner peu profond un référentiel avec le «-profondeur 1”Option, faites des mises à jour de commits et d'obtention / tirer. Cependant, cette approche peut entraîner des problèmes mineurs, tels que:
Dans l'ensemble, le clonage peu profond avec -pth 1 peut être utile pour obtenir rapidement une copie du référentiel, mais ce n'est peut-être pas la meilleure option si vous avez besoin d'accéder à l'historique complet du code.
Comment le repo Git Clone / Copie avec «-depth 1», faites-le et obtenez à nouveau des mises à jour / tirez les mises à jour?
Pour clone superficiel un référentiel git particulier avec la profondeur 1, créez à nouveau des mises à jour, parcourez d'abord le référentiel local. Ensuite, clonez le référentiel distant avec la profondeur 1 en utilisant le «Git Clone -depth 1 " commande. Ensuite, passez au référentiel cloné, apportez des modifications et engagez-les. Après cela, effectuez des opérations de poussée et de traction.
Étape 1: Passez au référentiel local
Tout d'abord, tapez la commande suivante et redirigez vers le référentiel local souhaité:
$ cd "C: \ git \ local_repo
Étape 2: Clone Remote Repository
Ensuite, clonez ou copiez le référentiel distant particulier en utilisant le «clone git«Commande avec la profondeur souhaitée et l'URL HTTP du référentiel GitHub:
$ Git Clone - Depth 1 https: // github.com / laibayounas / démo.git
Ici le "-profondeur«Option avec un«1”La valeur obtient uniquement le dernier engagement:
Étape 3: Passez au référentiel distant
Ensuite, passez au référentiel cloné via le «CD" commande:
$ CD Demo
Étape 4: Vérifier le journal de référence
Ensuite, vérifiez le journal de référence pour afficher l'historique des commits:
$ git réflog .
On peut observer que le référentiel distant a été cloné avec le dernier engagement:
Étape 5: Créez un nouveau fichier
Maintenant, faites un nouveau fichier dans le référentiel cloné actuel:
$ touch newfile.SMS
Étape 6: Suivre le fichier
Suivez le fichier nouvellement créé à l'aide du "git ajouter" commande:
$ git ajouter newfile.SMS
Étape 7: commettre des modifications
Après cela, exécutez la commande ci-dessous pour commettre des modifications:
$ git commit -m "newfile.txt ajouté "
Étape 8: Vérifiez l'histoire
Ensuite, vérifiez le journal de référence pour vérifier les modifications:
$ git réflog .
On peut voir que le nouvel commit a été ajouté à l'histoire de la validation:
Étape 9: Poussez les modifications à GitHub
Exécutez la commande ci-dessous pour pousser les nouvelles modifications dans le référentiel GitHub:
$ git push
Selon l'image fournie ci-dessous, les modifications ont été poussées vers le référentiel git distant:
Étape 10: Tirez les modifications de la télécommande
Maintenant, obtenez les mises à jour distantes du référentiel cloné à l'aide de la commande suivante:
$ git pull
La sortie ci-dessous montre que le référentiel est déjà à jour, ce qui indique qu'il n'y a pas de nouvelles modifications dans le référentiel distant:
Maintenant, supposons qu'un autre utilisateur ait apporté des modifications au référentiel distant et que vous souhaitez effectuer l'opération de traction, alors vous n'obtiendrez que les modifications les plus récemment appliquées:
$ git pull
Il peut être montré dans la sortie ci-dessous, seuls les modifications les plus récemment ajoutées ont été téléchargées:
Étape 11: Vérifiez les modifications
Enfin, exécutez la commande ci-dessous pour s'assurer que les modifications appliquées récemment sont apportées dans le référentiel cloné localement:
$ git réflog .
Comme vous pouvez le voir, l'historique des engagements ne contient que les derniers changements:
Il s'agissait de cloner superficiel un référentiel Git avec la profondeur 1, de créer des commits et de retirer à nouveau les mises à jour.
Conclusion
Il est généralement sûr de cloner peu profond un référentiel avec le «-profondeur 1”Option, créez des commits et tirez les mises à jour. Cependant, cette approche peut entraîner des problèmes si l'historique du référentiel est modifié pour affecter les commits que les utilisateurs ont fait. De plus, le clonage superficiel d'un référentiel avec -depth 1 ne télécharge que les derniers commits et n'inclut pas l'historique complet du référentiel. Cela signifie que les utilisateurs ne peuvent pas accéder au contexte complet du référentiel. Cet article a expliqué le clonage superficiel d'un référentiel Git avec la profondeur 1, la création de commits et la mise à jour de mises à jour.