Tutoriel de branchement GIT pour les débutants
- 691
- 208
- Victor Charpentier
La ramification permet à Git de suivre plusieurs lignes de développement. Cela vous permet essentiellement d'avoir plusieurs versions de votre projet en développement en même temps. Par exemple, de nombreux projets choisiront une branche maîtresse stable tandis que de nouvelles fonctionnalités ou des corrections de bogues sont implémentées dans une branche de développement ou de test. Une fois que les organisateurs du projet sont convaincus que les modifications apportées dans la branche de développement ont atteint le niveau de maturité requis, ils peuvent choisir de fusionner ces changements dans la branche principale.
Pour de nombreux projets plus grands, ce cycle sera souvent répété indéfiniment. L'avantage de la mise en œuvre de cette stratégie est qu'il contribue à réduire l'introduction des erreurs dans la version principale de la base de code et réduit donc la survenue de bogues et d'autres comportements négatifs potentiels dans le logiciel. Simultanément, il permet aux développeurs de tester de nouvelles idées sans restrictions. Par conséquent, ils peuvent continuer à contribuer de manière créative au projet de manière efficace.
Dans ce tutoriel, vous apprendrez:
- Qu'est-ce que la ramification
- Comment créer des branches
- Comment basculer entre les branches
- Comment supprimer les succursales
- Comment fusionner les branches
- Comment gérer les balises
- Comment utiliser des balises pour garder une trace du versioning
- Comment travailler avec les branches et les étiquettes sur les référentiels distants
Tutoriel de branchement GIT pour les débutants Exigences et conventions logicielles utilisées
| Catégorie | Exigences, conventions ou version logicielle utilisée |
|---|---|
| Système | Tout système d'exploitation GNU / Linux |
| Logiciel | Git |
| Autre | Accès privilégié à votre système Linux en tant que racine ou via le Sudo commande. |
| Conventions | # - Exige que les commandes Linux soient exécutées avec des privilèges racine soit directement en tant qu'utilisateur racine, soit par l'utilisation de Sudo commande$ - Exige que les commandes Linux soient exécutées en tant qu'utilisateur non privilégié régulier |
Création de branches
Examinons un exemple rapide de la façon de travailler avec les succursales, en continuant avec le projet GIT initial que nous avons créé dans le tutoriel GIT précédent pour les débutants. Tout d'abord, faites de ProjectName votre répertoire de travail actuel. Créons maintenant une branche spécifiquement pour travailler sur la documentation du projet OUT. Émettez la commande suivante pour faire de cette nouvelle branche.
$ Git Branch Docs
Maintenant, jetons un coup d'œil à toutes nos branches.
Branche Git $
Simplement émettre le branche git La commande comme ci-dessus affiche une liste de toutes les branches de notre repo git. Vous remarquerez que la première branche est appelée maître par défaut. Dans notre cas, nous voyons le maître branche et notre branche de documents nouvellement créée. Notez que la branche actuelle dans laquelle nous travaillons est marquée par * Et c'est toujours la branche maîtresse. Pour commencer à travailler dans la branche des documents, nous devons vérifier la branche.
Commutation entre les branches
$ docs de caisse
Maintenant que nous avons vérifié le docs branche, toutes les modifications que nous apportons affecteront cette branche seule et le maître La succursale restera intacte et dans l'état exact où il se trouvait avant de vérifier le docs bifurquer.
Permet de créer un réadmettre.SMS dossier pour notre projet.
$ echo "Ceci est un programme Hello World simple qui a été créé lors d'un tutoriel GIT."> Readme.SMS
Maintenant que nous avons un fichier de lecture descriptif pour la documentation, mettons-le et engageons-le comme nous l'avons appris à faire dans le précédent tutoriel GIT pour les débutants.
$ git ajouter readme.txt $ git commit -m "Ajout de la lecture à la branche des documents"
Maintenant que nous avons commis le changement dans notre branche de documents, nous pouvons revenir à la branche maître en le vérifiant.
$ maître de paiement
Allez-y et énumérez le contenu du répertoire.
$ ls
Vous remarquerez que la branche maîtresse n'a pas le réadmettre.SMS fichier car pour le moment il n'existe que dans la branche des documents. Cela montre comment les deux branches représentent deux états de développement distincts.
Branches de fusion
Maintenant, que se passe-t-il si nous pensons que notre documentation est complète et prête à être fusionnée dans la branche principale? C'est là que la commande Git Merge est utile. Entrez la commande suivante pour fusionner la branche des documents dans la branche maîtresse.
$ git fusiter les documents
Énumérez le contenu du répertoire et observez que la branche principale contient désormais le Readme.fichier txt.
$ ls
Si nous délivrons
$ git journal
Ensuite, nous voyons que l'historique des journaux des deux branches a également été fusionné ensemble.
Vérifier le journal GIT Suppression des succursales
Maintenant que nous avons terminé notre documentation et fusionné la succursale des documents avec la branche principale, nous pouvons supprimer en toute sécurité la succursale des documents si nous le souhaitons. Pour ce faire, ajoutez simplement le -d Flag à la commande Git Branch.
$ Git Branch -d Docs
Maintenant, nous n'avons plus qu'une seule branche dans notre projet et cela reflète tous les changements que nous avons apportés tout au long; y compris l'ajout d'un fichier readme.
Marquage
Nous pourrions vouloir être en mesure de voir et de référer facilement à un engagement spécifique sans avoir à utiliser son identifiant de validation. Pour ce faire, nous pouvons utiliser la commande git tag pour donner un nom mémorable. Dans notre cas, nommons notre coup de poing init, Notre deuxième engagement source Et notre dernier engagement réadmettre de sorte que si nous en avons besoin à l'avenir, nous pouvons facilement nous référer aux commits où nous avons initialisé le projet, ajouté le code source et ajouter un fichier ReadMe respectivement.
$ git tag init abbda7da6f6257effc7da16766ffc464c4098a8e $ git tag source 41dccee5478129094c3cbcd08a26076a9aa370b $ git tag readme readme readme tag readme readme tag readme readme readme tag tag readme readme readme
Vous remarquerez peut-être que pour la dernière commande, nous n'avons pas à spécifier un identifiant de validation. En effet. Nous aurions pu fournir la carte d'identité si nous le voulions, mais cela aurait été inutile.
Si nous utilisons la commande TAG sans aucun argument, cela nous donnera une liste de toutes les balises que nous utilisons.
$ git tag
Si nous voulons voir toutes les balises avec les autres informations de validation, nous pouvons émettre la commande de journal familier:
$ git journal
Tagging Git Désormais, lorsque nous voulons référencer ces commits, nous pouvons utiliser leurs balises à la place de leurs identifiants de validation. Tout comme nous pouvons vérifier une branche, nous pouvons également vérifier un engagement spécifique. Si nous décidions que nous voulions vérifier notre premier engagement, nous pourrions maintenant le vérifier en utilisant sa balise.
$ git Checkout init
À partir de ce moment, si nous décidions que nous voulons créer une nouvelle branche qui est allée dans une direction complètement différente de celle de notre projet d'origine, nous pourrions le faire en apportant des changements ici et en émettant la commande Switch avec l'indicateur -c suivi du nouveau nom de branche. Semblable à la commande de paiement, Switch modifie les branches, mais avec l'indicateur -c, il est également capable de créer simultanément une nouvelle branche.
$ git switch -c new-ranch-name
Vous pouvez également créer une nouvelle branche et y passer avec la commande de caisse comme suit.
$ git Checkout -B New-Branch-Name
Utilisez ce que vous préférez, mais il est important de noter que selon l'homme de Git, la commande Switch est expérimentale et que sa fonctionnalité pourrait changer à l'avenir.
autres considérations
Nous utilisons un exemple très simple afin de nous concentrer sur Git lui-même plutôt que sur le code que nous gérons. En conséquence, les balises que nous avons utilisées reflètent un schéma de dénomination simple basé sur l'introduction des fonctionnalités. Cependant, les projets plus grands utiliseront généralement les balises comme moyen de suivre le versioning en marquant les engagements qui correspondent à des numéros de point de libération spécifiques.
Par exemple, version1.0,
version 2.0 etc. Il est également important de noter que lorsque vous poussez vos modifications à un serveur distant, les nouvelles branches et balises ne sont pas poussés par défaut et doivent être spécifiquement poussés à l'aide des commandes suivantes.
$ git push origine new_branch_name $ git push origin tag_name $ git push origine --tags
La première commande appuyera la branche spécifiée sur le serveur distant, le second appuyera la balise spécifiée vers le serveur et le troisième appuyera toutes les balises vers le serveur.
Une autre chose importante à noter concernant les serveurs distants est que si vous avez cloné un repo distant, la branche maîtresse s'est clonée sur votre machine locale, mais pas les autres branches.
Pour voir toutes les autres branches sur le repo distant émettent la commande suivante à l'aide du -un drapeau qui montre toutes les branches locales et distantes.
$ Git Branch -a
Une fois que vous aurez vérifié une branche distante, il sera téléchargé sur votre répension locale et vous pouvez continuer à travailler dessus localement jusqu'à ce que vous souhaitiez repousser les modifications que vous avez apportées à la branche vers le serveur.
Conclusion
Après avoir travaillé sur les exemples ci-dessus, je vous encourage à continuer à jouer avec des branches et des étiquettes jusqu'à ce que travailler avec eux commence à vous sentir intuitif. Si vous n'avez pas accès à un référentiel distant où vous pouvez pratiquer des choses comme pousser les branches, pousser des balises et vérifier les branches distantes, je vous encourage à créer un compte GitHub gratuit et à sélectionner l'option pour créer un repo privé là-bas.
En fait, je recommanderais de le faire même si vous avez accès à d'autres références distantes. Si vous faites une erreur sur votre propre compte GitHub privé pendant que vous apprenez, il n'y a pas de mal majeur. Je vous recommande de commencer à utiliser Git en collaboration une fois que vous commencez à vous sentir super à l'aise avec elle.
Après avoir suivi cet article et le Git Tutorial for Beginners Guide, vous devriez maintenant vous sentir à l'aise d'installer Git, de configurer Git, de travailler avec les branches, le concept de version, de taggage et d'utilisation de Git pour travailler avec des référentiels locaux et distants. Vous avez maintenant les connaissances pratique pour prendre le pouvoir et l'efficacité de Git en tant que système de contrôle de révision distribué. Quoi que vous travaillez, j'espère que ces informations modifieront la façon dont vous pensez à votre flux de travail pour le mieux.
Tutoriels Linux connexes:
- Tutoriel GIT pour les débutants
- Mint 20: Mieux que Ubuntu et Microsoft Windows?
- Comment faire des mises à jour Pacman dans Arch Linux
- Tutoriel d'introduction à Git sur Linux
- Liste des meilleurs outils Kali Linux pour les tests de pénétration et…
- Manjaro Linux vs Arch Linux
- Système linux hung? Comment s'échapper vers la ligne de commande et…
- Git: Renommer la branche
- Comment mettre à jour les packages Ubuntu sur Ubuntu 22.04 Jammy…
- Liste des applications Git GUI pour Linux