Gestion et administration des succursales dans GIT

UNE branche dans Git c'est une branche de notre référentiel, c'est un moyen de générer un chemin alternatif vers le chemin principal. Cela nous permet d'explorer de nouvelles solutions sans avoir à modifier la base du programme ou de l'application que nous exécutons.
Cependant la notion de branche Ce n'est pas très clair quand on commence à utiliser cet outil qui contrôle les versions de nos projets. Habituellement, dans d'autres systèmes de contrôle de version, les ramifications d'un projet avec ce concept ne sont pas prises en compte.
Beaucoup utiliseront déjà Git et ils n'ont pas prêté plus d'attention à branches, et d'une certaine manière c'est compréhensible puisque lors de la manipulation d'un seul branche et si le développement est effectué par une seule personne, il ne devrait y avoir aucun inconvénient.
Mais que se passe-t-il si cette personne veut tester certaines fonctionnalités expérimentales qui peuvent faire échouer son projet ou simplement affecter la stabilité du projet, certains diront qu'un fourchette du projet et continuer à expérimenter et si l'amélioration est réussie, alors pensez à intégrer ce qui a été fait dans la fourche dans le projet principal. C'est vraiment un travail un peu long et inutile.
Dans le cas ci-dessus, il suffit de créer un nouveau branche au sein du projet en question, nous pouvons faire tous les changements et expérimentations souhaités et à la fin simplement en faisant un fusionner ou fusion avec le branche initial ou principal, nous aurons déjà rejoint tous nos changements.
Un autre casUn autre cas est lorsque nous avons une équipe de travail où deux personnes travaillant sur le même code peuvent générer des conflits, c'est là que Git fait ressortir sa puissance. Nous pouvons créer une structure de trois branches par exemple, un branche pour chaque développeur et un branche d'unification. De cette façon, chaque développeur peut prendre ses modifications et lorsqu'il sent qu'il peut les apporter au projet, il les envoie au branche d'unification et ainsi l'autre personne ou les autres membres de l'équipe peuvent y accéder.
Nous comprenons déjà les raisons qui nous poussent à utiliser branches et nous connaissons le concept, nous allons maintenant voir une partie qui est vitale pour l'utilisation de cette fonctionnalité de Git et est de mettre un nom sur notre branche.
Nom de la filialeA travers le nom, c'est que nous saurons où nous en sommes en ce moment, ce nom est totalement arbitraire, c'est-à-dire que chaque utilisateur de Git vous pouvez nommer votre branches comme vous le souhaitez dans votre projet. habituellement Git créer un branche appelé Maître Par défaut et c'est généralement celle qui contient la version stable et sans bug du projet, cependant on peut la renommer voire la supprimer si on en a envie, bien qu'il soit déconseillé de le faire.
Comme nous pouvons utiliser des caractères génériques de recherche, nous pouvons nommer notre branches hiérarchiquement, par exemple, Imp_Bug / 89 ou alors Impl_Bug / 23. Cela nous permet de les localiser et de les organiser avec des thèmes. Voyons comment nous prenons l'explication dans notre référentiel de test :
Dans ce cas, nous avons un directeur de succursale et nous avons créé plusieurs branches qui servent à résoudre les bogues, si nous exécutons la commande branche git dans la console Git dans le dossier de notre projet, nous obtiendrons une liste avec tous les succursales existantesVoyons à quoi cela ressemble lorsque nous l'exécutons :

Nous voyons alors la liste de tous nos branches et dans une couleur différente, nous voyons la branche dans laquelle nous sommes au bon moment. Mais que se passe-t-il si nous avons beaucoup de branches et nous devons filtrer uniquement les branches de résolution de boguesEh bien, c'est là que la recherche par caractères génériques entre en jeu. Par exemple, si nous voulons effectuer une recherche de cette manière, nous devons effectuer une commande similaire à la suivante :

git show-branche impl_bug / *

Voyons à quoi cela ressemble sur notre console :

On peut alors remarquer que tous les branches et d'un côté nous avons le commentaire du dernier s'engager cela a été fait en eux.
Parce que le dénomination de la branche C'est quelque chose de totalement arbitraire et de l'avis de l'utilisateur, il y a souvent de la confusion au sein d'une équipe, c'est pourquoi nous pouvons suivre certaines recommandations et meilleures pratiques, de cette façon nous serons de meilleurs utilisateurs au sein de l'outil :

• Bien que nous puissions utiliser le symbole / dans le nom de nos branches, cela ne peut pas être le caractère final d'un nom.
• Nous ne pouvons pas placer un point (.) après une barre oblique (/).
• On ne peut pas placer deux points de suite (… ) au sein d'un nom.
• Nous ne devons pas utiliser de caractères spéciaux (~ : ? * [ ) puisque ces caractères ont un sens dans la syntaxe de Git et ils peuvent être sujets à des erreurs.
• Nous ne devrions pas non plus avoir d'espaces vides ou de caractères de contrôle ASCII.

Si nous suivons ces directives, nous maintiendrons une utilisation appropriée au sein de notre référentiel, ainsi que les autres membres de l'équipe nous remercieront de leur avoir facilité la vie.
Si nous avons un liste des succursales et nous sommes dans un branche mais on veut passer à un autre, il suffit d'utiliser la commande suivante :

git checkout nom de branche

Avec ça on va changer branche immédiatement, pouvant ainsi travailler sur différentes sections du projet sans problème. Voyons comment nous pouvons changer de branche au sein de notre référentiel de tests :

Comme nous l'avons remarqué, c'est quelque chose d'assez simple, cependant si nous faisons un changement au sein de cette branche et que nous ne le faisons pas s'engager en essayant de changer pour un autre, nous obtiendrons une erreur et Git Il nous dit que nous devons faire quelque chose car sinon, les changements peuvent être perdus :

Lorsque ce problème se produit, nous devons faire un s'engager puis passer au suivant branche on verra le contenu de l'autre branche.
Pour créer une nouvelle branche, nous continuerons à utiliser la commande vérifier, mais dans ce cas, nous devons ajouter le -b option, avec cela, nous allons faire une copie de la branche actuelle et en générer une totalement nouvelle. Voyons à quoi cela ressemble sur notre console :

Nous remarquons comment une fois créé la nouvelle branche immédiatement Git nous amène à lui et nous pouvons commencer à travailler directement.
Bien que ce ne soit pas très courant, il existe des cas dans lesquels nous souhaitons supprimer une branche de notre référentiel et Git nous permet de le faire, seulement nous ne pouvons pas supprimer la branche dans laquelle nous nous trouvons actuellement, pour éviter les incohérences avec l'outil. Pour effectuer cette opération il suffit d'appliquer la commande suivante :

git branch -d nom-branche

RestrictionsCependant, il existe certaines restrictions, par exemple nous ne pouvons pas supprimer un branche Qu'est ce qui ne va pas avec ça s'engage qu'il branche d'où nous essayons de l'effacer n'a pas, avec elle Git permet d'éviter la perte d'informations, si nous voulons supprimer une branche de ces caractéristiques, nous devons faire fusionner dans notre branche ou allez dans celui qui en a s'engage.
Voyons à quoi ressemble l'exécution de cette commande dans la console :

À la fin de son exécution, nous voyons comment Git confirme la suppression de la branche correspondante.
Il y a des moments où nous avons touché la même ligne dans un fichier dans deux branches différentes, ceci au moment de faire fusionner cela va générer un conflit pour nous. Git Cela nous aide en établissant une différenciation du conflit dans le fichier, donc lors de sa résolution, nous devons faire un nouveau s'engager et un nouveau fusionner. La différenciation s'affiche comme suit dans le fichier en question :

 n'importe quelle ligne <<<<<< >>>>>> dev: NewChange 

Si nous voulons résoudre le conflit, nous devons supprimer le contenu de Gite, c'est-à-dire les lignes avec <<<<< Oui >>>>, donc on laisse le changement qu'on veut ou on unifie tout, en le faisant déjà Git ne nous présentera plus l'erreur et nous pourrons faire le fusionner d'habitude.
ImportantL'une des choses qu'il est important de faire est de générer un nomenclature partagée, c'est-à-dire établir une structure de noms sous laquelle les branches en fonction de sa fonction au sein du projet, de cette façon nous aurons beaucoup plus d'ordre, bien sûr cette nomenclature doit suivre les bonnes pratiques mentionnées au début du tutoriel.
Avec cela, nous terminons ce tutoriel, nous pourrons tirer beaucoup plus de notre référentiel dans Git et avec elle gérer notre équipe d'une excellente façon. Nous devons déjà avoir la base couverte pour la gestion des branches dans Git, avec cela, nous pouvons faire une administration adéquate de nos changements afin que nous puissions minimiser les conflits, surtout lorsque nous travaillons en équipes de deux personnes ou plus.Avez-vous aimé et aidé ce tutoriel ?Vous pouvez récompenser l'auteur en appuyant sur ce bouton pour lui donner un point positif