Utilisation de Git Subtree pour les projets WordPress • WPShout

Strap in folks, this is a nerdy one. Si vous n'êtes pas encore un peu conscient du rôle de Git dans votre vie, il y a de fortes chances que cet article ne fonctionne pas pour vous. Bien que je m'assurerai d'ancrer notre conversation sur l'utilisation de Git Subtree dans mon développement WordPress avec un petit contexte de ce qu'est Git, ce sera minime. Ce n'est pas un tutoriel "Git", c'est assez explicitement un tutoriel "git subtree".

Je ne pense pas sous-arbre git est bon pour tout le monde. Souvent, je ne pense même pas que ce soit bon pour moi. Mais lorsque certaines réalités de notre structure organisationnelle et historique de mon travail ont exigé que j'apprenne à l'utiliser pour le développement de WordPress, je l'ai fait. Et donc mon objectif ici est d'expliquer pourquoi Git Subtree était nécessaire pour mon (très aimé) système de déploiement Git Push to WP Engine. Et parce que c'est assez près une carte de toutes les parties de sous-arbre git, Je pense que cela peut aussi aider quelques personnes non WordPress. Permet d'y arriver!

Qu'est-ce que Git?

En bref, Git est un logiciel de contrôle de version. Cela signifie que je peux utiliser Git pour comprendre l'historique de mon code, quel était son statut un jour particulier, qui était responsable de quels changements sur une ligne de code spécifique, etc.

Nous supposerons que si vous comprenez cela, vous serez également familiarisé avec les modèles de base de Git. Que tu te comprennes git pull pour recevoir les modifications d'une copie locale d'un projet, et git push les partager avec d'autres sur Github, Bitbucket, Gitlab, etc.

Pourquoi utiliser le contrôle de version distribué?

Strictement et surtout, Git n'est pas seulement un "logiciel de contrôle de version", il est distribué logiciel de contrôle de version. Cela présente de nombreux avantages par rapport à ses alternatives centralisées, comme Subversion. En étant distribués, les gens peuvent travailler de manière asynchrone et n'ont généralement pas trop de complications pour résoudre les problèmes de changement de fichier simultané, aussi appelés «fusionner les conflits». (Ne vous inquiétez pas, ils se produisent quand même. Et la plupart des développeurs les craignent au moins un peu, même moi.)

De plus, en étant distribué (et, par conséquent, avec des branchements bon marché), Git est un très bon outil de déploiement. Donc, simple git push production master fonctionne très bien pour placer tous les fichiers de votre site WordPress directement sur les hôtes qui le prennent en charge. Lorsque vous entrez dans des configurations plus complexes, cela peut s'effilocher sur les bords. Mais pour de nombreux sites WordPress, c'était bien plus que suffisant.

Pourquoi Git au lieu de SVN ou Mercurial?

Pourquoi Git? J'adore aborder ça juste parce que git me dérange pas mal. je me sens comme gitLa CLI n'est pas aussi bien conçue que les autres avec lesquelles je me suis penchée de temps en temps, de manière plus pertinente Mercurial et Subversion.

Mais, pour le pire, pour des raisons complexes (et simples), le monde a tous convergé vers Git en tant que système de contrôle de version distribué de choix. Le succès d'entreprises comme Github et Gitlab doit tout au succès sous-jacent de Git par rapport à ses concurrents. Donc en partie Git parce que Git est bon. Partiellement git car faire quoi que ce soit d'autre pour le contrôle de version de nos jours est loufoque et difficile à justifier. 🤪

Git Subtree vs Sous-modules

Le principal problème pour lequel nous utilisons des sous-arbres Git dans ce projet est le même que celui utilisé par les autres utilisateurs pour les "sous-modules Git". Dans les deux cas, le problème est «J'ai du code que je souhaite conserver dans un référentiel Git séparé. Mais je veux utiliser ce code dans ce projet. » BTW: Composer est la réponse PHP la plus recommandée pour ce problème, et je continue de ne pas savoir comment mélanger au mieux les flux de travail WordPress. (Si vous avez des opinions bien arrêtées à ce sujet et que vous souhaitez écrire à leur sujet pour WPShout, envoyez un e-mail à "david" sur ce domaine. Je serais ravi de publier un ou deux articles à ce sujet. 🤓)

Donc, pour réutiliser le code d'un autre projet, nous avons des sous-arborescences et des sous-modules. Si l'un d'entre eux est plus populaire, à mon avis, il s'agit certainement de sous-modules Git. Voici les différences fondamentales telles que je les comprends:

• Contrôle des fichiers: Une sous-arborescence Git extrait tous les fichiers dans le système de fichiers du référentiel Git de vos projets. Un sous-module Git ne les ajoute pas à l'historique de votre projet.
• Histoire + fusion: avec les sous-arborescences Git, vous avez des validations qui fusionnent explicitement dans les modifications du référentiel distant. Dans les sous-modules, ces modifications sont suivies avec une modification de la .gitmodules fichier.

Comment j'utilise Git Subtree

Donc, si les sous-modules Git sont plus populaires, pourquoi est-ce que j'utilise des sous-arbres? Premièrement: j'ai un repo géant de tous les fichiers non Core sur un site WordPress. Ce qui signifie tous les plugins, tous les thèmes, et donc tout efficacement contenu wp MAIS les fichiers multimédias. Et j'ai un plugin WordPress que nous maintenons de manière indépendante car il est également installé sur une variété d'autres sites, à l'exception de ce "monorepo". J'utilise donc une sous-arborescence Git pour suivre les modifications apportées au plugin dans mon référentiel "site WordPress", et pouvoir git push ces changements de production.

WP Engine permet à Git Push deploys avec Subtree

Afin de pousser mon «sous-référentiel» vers le serveur de production WP Engine, j'ai besoin que ses fichiers soient reflétés dans l'historique Git. Et pour ce faire, j'ai été obligé d'utiliser Git Subtree. Ma dernière utilisation des sous-modules Git était dans le vague espoir de pouvoir les utiliser sur ce projet. Mais j'ai réalisé que ma précieuse fonctionnalité Git push) sur WP Engine) nécessitait que sous-arbre git au lieu. C’est ce que j’ai maintenant.

Pour configurer tout cela, il y a vraiment trois étapes de base:

1. Ajoutez votre «sous-dépôt» en tant que télécommande Git

Tout d'abord, nous voulons simplement nous éviter d'avoir à traiter avec une longue URL Github / Gitlab / etc, alors définissons cette télécommande comme une branche pour obtenir un nom plus court. Au cas où ce ne serait pas évident, dans tous les extraits qui suivent, vous allez remplacer MyGitSubRepo avec le «slug» réel que vous souhaitez utiliser pour votre projet, capitalisé et ponctué comme vous le souhaitez. Quoi qu'il en soit, la commande est:

git remote add -f MyGitSubRepo https://github.com/davidbhayes/MyGitSubRepo.git

2. Ajoutez cette nouvelle télécommande en tant que sous-arborescence

Une fois que nous avons obtenu cette télécommande, nous devons indiquer à Git où elle doit placer les fichiers de notre sous-arborescence. Parce que mon référentiel est essentiellement "un site WordPress" et mon sous-référentiel est un plugin WordPress, cette commande ressemblait à ceci pour moi:

git subtree add --prefix wp-content / plugins / MyGitSubRepo MyGitSubRepo master --squash

Ce qui se passe, c'est que Git va alors tirer (et écraser) le Maître branche de votre référentiel et validez la branche en cours sur l'état actuel de cette branche sur votre sous-référentiel.

(Encore une fois, remplacez tous MyGitSubRepo avec la véritable branche de raccourci qui correspond à la façon dont vous pensez de votre projet.)

3. Pour les modifications futures, récupérez et tirez votre sous-arbre Git

Ce qui précède aura initié et récupéré tous vos fichiers une fois. Mais il est fort probable que vous ayez poursuivi cette configuration, car vous voulez pouvoir extraire les modifications de votre sous-référentiel Git au fil du temps en utilisant le commentaire de la sous-arborescence git. Cela se fait essentiellement en (1) mettant à jour votre copie locale du référentiel distant avec un git fetch puis (2) git subtree pulldans les changements, avec une commande très similaire au premier pull:

git fetch MyGitSubRepo
git subtree pull --prefix wp-content / plugins / MyGitSubRepo MyGitSubRepo master --squash

Parce que je n'ai presque jamais besoin / envie d'exécuter ces commandes indépendamment les unes des autres, j'ai un peu update-MyGitSubRepo.sh script que je peux exécuter pour transformer les deux étapes complexes en une simple ligne. Mais ce n'est en aucun cas nécessaire, et une explication plus approfondie de cela n'est pas vraiment dans le champ d'application de cet article.

Un Gotcha qui me rapporte beaucoup

Faire tout ce qui précède fonctionnera généralement assez bien pour garder votre sous-arbre Git à jour pour votre plugin WordPress. Il y a cependant un problème commun: sous-arbre git exige que votre copie de travail locale soit «propre». Par propre, je veux dire que il n'y a pas de changements non suivis dans Git.

Rendre votre référentiel Git «propre» avant de mettre à jour avec l'étape 3 ci-dessus n'est pas trop difficile. Cela signifie surtout que votre statut git devrait être vide. Et 90% du temps, avant de courir, ça marche pour moi. Sinon, votre commande échouera avec un L'arbre de travail a des modifications. Impossible d'ajouter. réponse.

Parfois, je reçois cette erreur parce que j'ai oublié de nettoyer mon statut git. Mais je l'obtiens aussi parfois même quand je l'ai fait. Et c'est une erreur frustrante et déroutante.

Mais, comme je l'ai appris d'une belle réponse StackOverflow, la solution est une commande git que je ne connaissais pas:

git diff-index HEAD

Mon bref résumé de cette commande, après l'avoir utilisée, est que c'est comme un statut git avec des détails supplémentaires. Si souvent, ce que je trouve lors de son exécution, c'est qu'un fichier non suivi a été mis à jour, ou autre chose qui, pour diverses raisons statut git ne m'en a pas parlé. J'espère que vous n'en aurez pas besoin, mais j'espère aussi que vous en avoir parlé vous aidera quand vous le ferez.

Git Subtrees & WordPress: se ramifier dans Git; p

Je ne pense pas que la plupart des développeurs sur la plupart des sites WordPress doivent connaître Git Subtrees. Je pense que la plupart devraient utiliser Git 🤓

Mais j'espère qu'en résumant la façon dont j'utilise Git Subtrees (et non les sous-modules) avec WordPress, je vous ai donné un point de départ lorsque vous avez enfin une situation qui vous oblige à maintenir deux référentiels de code WordPress indépendants pour un seul site. Et si c'est le cas, j'espère que vous aurez trouvé cela un peu moins gênant à apprendre que moi. Bonne chance!