Flux de travail et utilisation avancés de Git

Récemment, nous avons examiné les bases pour commencer à utiliser Git pour le contrôle de code source dans vos projets. Bien que ce soit un excellent point de départ, il existe un tas d'autres commandes et workflows Git qui vous aideront à vous familiariser avec l'utilisation de Git dans votre travail de codage quotidien.

Flux de travail Git

Quand j'ai commencé à utiliser Git, j'ai pensé que je savais comment l'utiliser correctement. Mon approche idéale était d'effectuer toutes les modifications au même endroit sans branches, puis de les valider dans le référentiel et de continuer à travailler.

Même s'il valait mieux que de ne pas utiliser le contrôle de version, il m'a fallu un certain temps pour réaliser que je n'utilisais pas la majeure partie de la puissance fournie par Git. Pour que Git fonctionne pour moi, j'avais besoin d'une stratégie pour créer des branches et fusionner mes modifications.

Puis git-flow est sorti et je l'ai adopté comme stratégie. Je me souviens encore d'avoir eu l'impression de jeter un coup d'œil derrière un rideau là où se trouvaient les incroyables développeurs. J'avais maintenant un aperçu de leur fonctionnement et je pouvais commencer à devenir l'un d'entre eux.

Mais git-flow ne convient pas à tous les scénarios, donc pendant que nous allons l'examiner, nous allons également jeter un œil à quelques autres méthodes pour organiser vos projets Git, y compris la façon dont je gère mes projets en tant que développeur solitaire.

git-flow

En regardant git-flow maintenant, je reconnais que le paysage logiciel a beaucoup changé en 10 ans et git-flow n'est peut-être pas la meilleure option pour votre équipe. Lorsque git-flow a été écrit, il était rare de déployer une application plusieurs fois par jour. Au lieu de cela, vous avez probablement créé un numéro de version majeur et publié tous les quelques mois ou semaines si vous faisiez partie d'une équipe particulièrement agile.

Voyons ce qu'est git-flow.

Si vous voulez voir l'explication complète et approfondie avec des graphiques et des commandes Git pour Git Flow, vous devriez lire ce post.

Dans git-flow, deux branches ont une durée de vie infinie. Tout d'abord, main qui doit refléter le code prêt à être déployé dans votre environnement live/production.

Deuxièmement, nous avons notre branche de développement. Cette branche devrait avoir les dernières modifications prêtes pour la prochaine version de notre logiciel. Lorsque les modifications de develop sont prêtes à être déployées sur notre application en direct, nous les fusionnons dans la branche principale et les étiquetons avec le numéro de version qui correspond au numéro de version.

En dehors des deux branches principales, il existe trois types de branches de soutien.

1. Caractéristique

Une branche de fonctionnalité ne peut être créée qu'à partir de la branche de développement. Il doit être fusionné dans la branche develop. Le nommage peut être tout ce qui décrit la fonctionnalité sur laquelle vous travaillez.

Lorsque le travail est prêt pour la prochaine version, il est fusionné dans la branche de développement où il attend le moment de la publication.

2. Relâchez

Les branches release sont créées à partir de la branche develop et doivent fusionner à la fois develop et main. Vous nommez une branche de version avec la convention release-x. En pratique, cela signifie généralement que vous nommez une branche avec le numéro de version que vous prévoyez d'utiliser comme ceci : release-2.2

Vous utilisez une branche de publication pour effectuer la préparation finale de la publication de votre logiciel. Cela peut inclure le dépassement du numéro de version des fichiers, la vérification que vos traductions sont effectuées ou les vérifications finales du code.

3. Correctif

La branche de correctif est créée à partir de la branche principale et est utilisée pour contenir les modifications qui doivent être traitées immédiatement dans l'application en direct. Il peut s'agir d'un bogue à corriger ou d'un problème de sécurité à résoudre.

Une fois le problème résolu et déployé sur votre branche principale, vous balisez votre code avec le numéro de version approprié.

La principale raison pour laquelle les équipes n'utilisent pas git-flow maintenant est que la façon dont nous publions les logiciels a changé. Au lieu de publier des versions plus importantes moins souvent, vous pouvez publier une modification d'une application plusieurs fois par jour. Je sais que je pousse le travail sur les sites de mes clients plusieurs fois par semaine dès qu'il est prêt. Nous ne faisons pas les numéros de version du site, nous continuons simplement à l'améliorer.

Le git-flow standard n'est pas destiné à s'adapter à cela.

Flux Github

La deuxième option que beaucoup de gens utilisent est Github Flow.

La seule grande règle de Github Flow est que tout code se trouvant sur la branche principale peut être déployé à tout moment car il est prêt pour la production.

Toutes les branches sont créées à partir de la branche principale avec un nom descriptif pour tout ce que vous faites.

Une fois que vos modifications sont prêtes, vous créez une demande d'extraction.

Les demandes d'extraction indiquent aux autres personnes travaillant sur le même code que le travail que vous faites est prêt à être révisé avant que ces modifications ne soient fusionnées dans le code principal.

Une fois que vous avez soumis une demande d'extraction, l'équipe avec laquelle vous travaillez peut examiner les modifications et fournir des commentaires. Si la demande d'extraction est considérée comme prête à fusionner, elle est alors fusionnée dans la branche principale de votre projet.

Un inconvénient du flux Github pour un développeur unique ou une très petite équipe est que l'administration d'une demande d'extraction peut créer des frais généraux supplémentaires dans la gestion du projet. C'est pourquoi je ne les utilise pas dans mon travail.

Comment j'utilise les flux de travail Git avec des projets clients

Dans mon travail client, je suis généralement le seul à écrire quotidiennement du code pour un projet. Mon client peut mettre à jour des plugins WordPress ou modifier certains CSS, mais il ne fait aucun travail de codage majeur. Cela signifie que si j'utilisais le flux Github, je réviserais mes demandes d'extraction, ce qui ne ferait que créer des maux de tête de gestion supplémentaires. Regardons le système que j'utilise, qui ressemble à la fois à git-flow et à Github flow.

J'ai deux branches principales appelées main et staging. La branche principale suit le code en cours d'exécution sur le site de production. La branche intermédiaire suit tout ce qui est testé sur le site intermédiaire que nous utilisons pour tester les modifications avant de les transférer sur le site en ligne.

Chaque branche est créée à partir de la branche principale. Les nouvelles fonctionnalités reçoivent un nom comme celui-ci : feature/32-new-feature. Dans ce contexte, le nombre 32 correspond au numéro de ticket dans notre système de gestion de projet et les mots qui le suivent sont une brève description de ce sur quoi on travaille. Les correctifs de bogues sont nommés de la même manière, bug/20-bug-name.

Chaque branche créée est d'abord fusionnée dans notre branche intermédiaire, puis une fois approuvée par le client ou testée par moi-même, elle est fusionnée dans la branche principale. Ce flux de travail peut ressembler à ceci.

# fonctionnalité de fusion dans la branche intermédiaire

fonctionnalité de fusion git/32-nouvelle-fonctionnalité

# déployer et tester la fonctionnalité

git checkout principal

fonctionnalité de fusion git/32-nouvelle-fonctionnalité

# déployer la fonctionnalité sur le site en direct

Dans mes projets, j'ai mis en place un déploiement continu, ce qui signifie que chaque fois que je pousse du code vers main, il est automatiquement poussé vers le site en direct. Le même processus est mis en place pour la branche intermédiaire.

Si je travaillais avec une équipe capable de vérifier mon code dans un flux de travail de demande d'extraction, j'utiliserais ce système car il fonctionne bien en équipe. Pour un développeur travaillant principalement seul, ce sont simplement les frais généraux de gestion qui vont ralentir votre flux de travail.

Commandes Git avancées que j'utilise

Maintenant que nous avons une idée de la façon dont nous pouvons utiliser Git dans un flux de travail pratique, examinons les commandes plus avancées qui seront nécessaires pour que cela se produise. J'utilise chacune de ces commandes au moins quelques fois par semaine lorsque je travaille avec le code de mon client.

Même si vous allez utiliser une application graphique (j'en ai mentionné quelques bonnes dans mon dernier article sur Git), il est toujours important de comprendre ce qui se passe en arrière-plan. Plusieurs fois, j'ai dû travailler via un terminal pour résoudre un problème créé par une application graphique Git.

Ajout de modifications par ligne

La seule commande qui m'a permis d'utiliser Git via Terminal click était git add -p. Jusqu'à ce que j'apprenne cette commande, j'utilisais des applications GUI parce que j'apportais des modifications à mon code mais que je souhaitais diviser des lignes spécifiques en différents commits afin de pouvoir expliquer pourquoi j'avais apporté une modification. Pour ce faire, j'ai utilisé une interface graphique pour sélectionner les lignes, mais git add -p vous guide à travers une interface interactive pour ajouter des modifications dans les morceaux.

Je l'utilise plusieurs fois par jour.

Suivre la branche Git distante

Si vous supprimez un référentiel existant et que vous avez des branches telles que main et staging dont vous devez suivre mais qui existent déjà, vous devez indiquer à vos versions locales des branches de suivre ces versions distantes de la branche.

Il y a quelques façons de le faire.

# Définir en amont lors de la poussée à distance

git push -u mise en scène d'origine

# Définir en amont

# suppose que vous êtes sur la branche que vous souhaitez actuellement suivre avec la télécommande

git branch -u origine/mise en scène

branche git --set-upstream-to=origine/mise en scène

# Si vous n'êtes pas sur la branche que vous souhaitez suivre, vous spécifiez la branche à la fin

git branch --set-upstream-to=origin/staging

Enregistrer les modifications sans les valider

Parfois, vous serez au milieu d'un travail qui n'est pas encore prêt à être validé, mais vous devez enregistrer son état. C'est là que git stash est utile. Cette commande stocke les modifications pour vous en supprimant les modifications. Vous pouvez les récupérer en utilisant git stash pop. Il y a quelques commandes supplémentaires pour rendre stash utile, mais ce sont les deux que j'utilise régulièrement.

Tirez un commit Git spécifique

Parfois, vous devez insérer un commit spécifique dans votre travail actuel. Avec un HEAD propre (vous n'avez encore apporté aucune modification), vous pouvez extraire un commit spécifique avec git cherry-pick . Vous pouvez trouver la documentation complète sur git cherry-pick ici.

Pour chaque commit, Git construit une longue séquence de lettres et de chiffres appelée objet Git, et communément appelée SHA. Étant donné que chaque commit en reçoit un, vous pouvez référencer un commit avec sa valeur SHA. En savoir plus sur les objets Git.

Jetez les changements dont vous n'avez pas besoin

À un moment donné de tout projet, nous allons apporter des modifications, puis réaliser que cela ne fonctionne pas et que nous devons simplement les supprimer et recommencer. Au lieu d'essayer simplement d'annuler jusqu'à ce que nous soyons de retour là où nous voulons être, nous pouvons utiliser la commande Git suivante pour supprimer toutes les modifications qui n'ont pas encore été suivies.

git reset --hard

La commande ci-dessus réinitialisera votre code à la validation la plus récente sur la branche sur laquelle vous travaillez actuellement. Nous pourrions également utiliser un <#commitSHA> avec cette commande pour réinitialiser à un commit spécifique si nous voulions revenir à un état antérieur au dernier commit. Vous pourriez peut-être l'utiliser pour réinitialiser la vérification initiale de la branche, car la totalité de la valeur du travail de la branche n'est pas quelque chose que vous souhaitez conserver, mais vous avez déjà suivi une partie du travail.

Pour aller plus loin, nous pouvons jeter tous les fichiers ou répertoires qui n'ont pas encore été suivis dans git avec la commande git clean.

git clean -fd : les drapeaux f et d indiquent à git de supprimer les fichiers et répertoires non suivis.

Supprimer les branches

Chaque semaine ou deux, je regarde les résultats d'une commande git status et je trouve que j'ai beaucoup trop de branches pour comprendre raisonnablement ce qui se passe dans mon référentiel. Cela signifie que je peux supprimer toutes les branches qui correspondent aux tickets qui ont été résolus avec les commandes suivantes.

# supprime la version locale

git branch -d $nom de la branche

# supprime la branche sur ma télécommande

git push $remotename --delete $branchname

Utiliser le contrôle de version

Bien que vous ne soyez peut-être pas un expert de toutes les commandes Git que vous utiliserez, une chose importante à retenir est que vous devez utiliser le contrôle de version . Même si vous êtes la seule personne à travailler sur un projet, l'utilisation de Git et d'un workflow Git vous aidera à organiser vos projets. Vous n'aurez pas besoin d'appuyer sur CTRL + Z tant que vous n'aurez pas réinitialisé votre travail après avoir écrit du code qui ne fonctionnait pas.

Vous pourrez faire confiance à votre système et continuer à produire du travail pour vos projets.

Essayez l'hébergement WordPress entièrement géré

Besoin d'un hébergement optimisé pour WordPress ? Découvrez les plans d'hébergement WordPress entièrement gérés de Nexcess dès aujourd'hui.