Si vous écrivez un logiciel pour gagner votre vie en 2018, alors je peux dire en toute confiance que vous êtes familier avec Git. L’outil créé par Linus Torvalds est devenu synonyme de contrôle de version. Et sans aucun doute, l’une des meilleures fonctionnalités de Git est la façon dont il supprime la douleur du branchement et de la fusion. Il existe plusieurs façons de créer une branche dans Git. Dans cet article, nous en passerons en revue certains. Ensuite, nous terminerons par une petite réflexion sur le modèle de branchement de Git et le branchement en général.

Créer une branche à partir du maître

Vous créez des branches dans Git, sans surprise, en utilisant la commande branch. Comme beaucoup d’autres commandes Git, « branch » est très puissante et flexible. Outre la création de branches, il peut également être utilisé pour les lister et les supprimer, et vous pouvez les personnaliser davantage la commande en employant une large liste de paramètres. Nous allons commencer par la première façon de créer une branche. Supposons que vous souhaitiez créer un nouveau dossier appelé « my-app », entrez-le et démarrez un nouveau dépôt Git. C’est exactement comme cela que vous « feriez »:

mkdir my-appcd my-appgit init

Vous avez maintenant un nouveau dépôt Git vide. Mais les dépôts vides sont ennuyeux. Alors qu’en est-il de créer un nouveau fichier de démarque avec « Hello World! » écrit dedans?

echo Hello World! > file.md

Si vous exécutez « git status », vous devriez voir un message indiquant que votre fichier n’est pas suivi:

Les fichiers non suivis ne sont pas non plus cool, alors faisons le suivi:

git add file.md

Et enfin, créons notre premier commit:

git commit -m "First commit"

Nous avons maintenant un dépôt avec une branche, qui a exactement un commit. Cela peut ne pas ressembler au chose la plus excitante au monde (parce que ce n’est vraiment pas le cas), mais c’est certainement moins ennuyeux que d’avoir un dépôt sans validation du tout, non? Maintenant, disons que pour une raison quelconque, vous devez modifier le fichier « s contenu. Mais vous ne » t envie de faire ça. Que faire si quelque chose ne va pas et que vous gâchez en quelque sorte le contenu magnifique et immaculé de votre fichier? (Ouais, je sais que c’est juste un fichier stupide avec « Hello World! » Dedans, mais utilisez les merveilleux pouvoirs de votre imagination et considérez le fichier comme un proxy pour un projet beaucoup plus complexe.) La solution à ce dilemme est, bien sûr, en train de créer une nouvelle branche:

git branch exp

Nous avons donc maintenant une nouvelle branche appelée « exp », pour l’expérimentation Certaines personnes habituées à utiliser différents systèmes de gestion des versions, en particulier les systèmes centralisés, pourraient dire que les branches ont le même «contenu». Ce n’est cependant pas tout à fait exact quand on parle de Git. Pensez aux branches comme des références qui pointent vers un commit donné.

Créer une branche à partir d’un commit

Supposons que, pour une raison quelconque, nous abandonnions notre expérience, sans en ajouter un seul s’engager dans la nouvelle branche. Revenons au master et supprimons la branche exp:

git checkout mastergit branch -d exp

Maintenant que nous « sommes revenus à une seule branche, ajoutons quelques commits, pour simuler le travail en cours:

Imaginez qu’après avoir fait tout ce « travail », vous apprenez que, pour une raison quelconque, vous devez remonter dans le temps. étaient juste deux lignes dans le fichier et créer de nouvelles modifications à partir de là. Mais en même temps, vous devez conserver la progression que vous avez déjà faite. En d’autres termes, vous voulez créer une branche à partir d’une validation antérieure. Comment feriez-vous cela ? Dans Git, chaque commit a un identifiant unique. Vous pouvez donc le voir facilement en utilisant la commande « git log ». Pour créer une nouvelle branche basée sur un commit spécifique, passez simplement son hachage comme paramètre à la commande branch:

git branch new-branch 7e4decb

En passant, vous n’avez même pas besoin de tout le hachage la plupart du temps. Seuls les cinq ou six premiers caractères le feront.

Créer une branche à partir d’une balise

Si vous « êtes un peu plus expérimenté avec Git, alors vous devriez être familier avec le concept de balises. Vous utilisez des balises pour indiquer qu’un commit donné est important ou spécial d’une certaine manière. Par exemple, les balises sont généralement utilisées pour indiquer les versions réelles d’un produit. Si vous travaillez dans votre application depuis un certain temps et vous pensez qu’il est temps de publier la version 1.0, ce que vous faites généralement est de modifier les numéros de version là où c’est nécessaire, de valider ces modifications et d’ajouter ensuite une balise à ce moment précis. Pour créer une balise, vous exécutez généralement quelque chose comme ceci:

git tag -a v1.0 -m "First major version"

Le paramètre « -a » indique que cela va pour être une balise annotée. Contrairement à une balise légère, il s’agit d’un objet Git à part entière, contenant des informations telles que le nom et l’adresse e-mail du validateur, l’horodatage et un message. Maintenant, vous avez une balise, une indication que ce point particulier de l’histoire est spécial et a un nom. Joli. Vous pouvez continuer à travailler, comme d’habitude, en créant et en validant les modifications qui feront partie de la version 1.1. Jusqu’à ce qu’un rapport de bogue arrive. Certains clients qui ont été mis à jour vers le 1.La version 0 du produit indique qu’une fonctionnalité d’importation ne fonctionne pas comme prévu. Eh bien, vous pourriez théoriquement corriger le bogue dans la branche principale et la déployer. Mais alors les clients recevraient des fonctionnalités potentiellement non testées et incomplètes. -non. Donc que fais-tu? La réponse: vous créez une nouvelle branche à partir de la balise que vous avez créée pour indiquer la version principale. Vous corrigez le problème là-bas, générez et déployez. Et vous devriez probablement la fusionner avec master par la suite, de sorte que les prochaines versions contiennent le correctif. . Comment procéderiez-vous? Facile:

git branch <NAME-OF-THE-BRANCH> <TAG>

Plus précisément, en utilisant notre exemple précédent:

git branch fix-bug-123 v1.0

Après cela, vous pouvez vérifier votre nouvelle branche comme d’habitude. Ou mieux encore, vous pouvez tout faire en une seule étape:

git checkout -b fix-bug-1234 v1.0

Création d’une succursale dans l’État principal détaché

Avez-vous déjà souhaité remonter dans le temps? Avec Git, c’est possible … du moins en ce qui concerne les fichiers de notre référentiel. Vous pouvez, à tout moment, extraire un commit si vous connaissez son hachage:

git checkout <SHA1>

Après avoir exécuté cela, Git vous montrera un message curieux:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Lorsque vous vérifiez un commit, vous entrez dans un état spécial c alled, comme vous pouvez le voir, « tête détachée ». Bien que vous puissiez valider des modifications dans cet état, ces validations n’appartiennent à aucune branche et deviendront inaccessibles dès que vous aurez extrait une autre branche. Mais que faire si vous souhaitez conserver ces validations? La réponse, sans surprise, est d’utiliser la commande « checkout » à nouveau pour créer une nouvelle branche:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

Et bien sûr, vous savez maintenant que vous pouvez écrire le deux dernières lignes en une seule commande:

git checkout -b new-branch-to-keep-commits

Assez facile, non?

Juste parce que vous pouvez … Ça ne veut pas dire que vous devriez

Le modèle de branchement de Git est l’un de ses arguments de vente. Il transforme ce qui, dans d’autres systèmes de contrôle de source, est un processus douloureux et même lent en un jeu d’enfant. On pourrait dire que Git a réussi à démocratiser le branchement pour le grand public. Mais il y a un sérieux danger. En raison du faible coût du branchement dans Git, certains développeurs peuvent tomber dans le piège de travailler avec des branches à très longue durée de vie ou d’employer des workflows ou des modèles de branchement qui retardent leur intégration. gration. En tant qu’industrie, nous y sommes allés. Nous avons fait cela. Cela ne fonctionne pas. Au lieu de cela, adoptez des flux de travail qui utilisent des branches de très courte durée. Vous aurez un bac à sable sécurisé dans lequel coder sans craindre de casser des choses ou de perdre du temps à vos collègues. Mais est-ce que cela vous amène à vous demander « Comment déployer du code avec des fonctionnalités partiellement terminées? » Dans ce cas, ce sont des indicateurs de fonctionnalités à la rescousse. Les branches Git sont un outil puissant. Utilisez-les à bon escient, et n’en abusez pas. Et lorsqu’ils ne suffisent pas, utilisez la livraison continue / l’intégration continue ainsi que les indicateurs de fonctionnalités – y compris les outils spécialisés à votre disposition – pour que vos applications puissent passer au niveau suivant.