Share
Si vous avez un plug-in hébergé sur le référentiel WordPress, vous serez assez familiarisé avec SVN et certaines de ses commandes. Dans ce tutoriel, je vais vous montrer comment utiliser Git, un autre système de contrôle de version popularisé par GitHub, pour publier et gérer votre plug-in..
Git et SVN sont deux exemples de systèmes de contrôle de version. Le référentiel de WordPress utilise ce dernier (si vous avez un plug-in hébergé sur WordPress, vous serez familiarisé avec le "check-in" pour apporter des modifications à ce référentiel). Ils vous permettent tous les deux de suivre les modifications apportées à votre code, mais il existe de grandes différences entre ces méthodes..
SVN s'appuie sur un "référentiel central" unique du code (dans notre contexte: le référentiel de plug-in WordPress). Chaque fois que vous souhaitez modifier votre plug-in, vous devez en créer une copie locale, y apporter les modifications, puis "archiver" ces modifications dans le référentiel WordPress..
Git est un système de contrôle de version décentralisé. Plutôt que de ne disposer que d'une copie locale de votre plug-in, vous disposez d'un clone complet de son référentiel de plug-ins, avec toutes ses modifications. Le référentiel existe maintenant de manière autonome sur votre ordinateur. Vous pouvez valider et suivre les modifications, annuler les modifications ou «déconnecter» votre plug-in dans différentes directions, le tout sur votre ordinateur local. Une fois que vous êtes heureux de mettre à jour votre plug-in, vous transmettez ensuite vos modifications à votre référentiel WordPress pour les rendre publiques..
Dans ce tutoriel, je suppose que vous avez un plug-in hébergé sur le référentiel de plug-in WordPress, ou du moins que votre demande d'hébergement a été approuvée. Si vous ne savez pas comment faire héberger votre plug-in par WordPress, je vous suggère de lire notre article sur la publication dans le référentiel de plugins WordPress..
Il existe de nombreux arguments pour et contre l'utilisation de Git sur SVN (ainsi que des systèmes de contrôle de version décentralisés en général). Beaucoup d'entre elles proviennent des manières fondamentalement différentes que Git et SVN suivent les changements. Vous trouverez une excellente analyse approfondie de Git et SVN dans l'article Git vs SVN de CodeForest, mais pour le développeur WordPress:
Un inconvénient de l'utilisation de Git, c'est de le rendre agréable à utiliser avec un référentiel SVN. Ce n’est pas si difficile grâce à git svn, et cet article est là pour vous guider.
Si vous ne l'avez pas déjà fait, vous voudrez installer Git. Comment installer Git est assez bien décrit dans le livre Git Community et le livre Pro Git (les deux excellent ressources si vous êtes nouveau sur Git). Comment installer Git dépend de votre système d’exploitation, ainsi que des programmes graphiques disponibles. Dans ce tutoriel, je vais tout faire en ligne de commande - et je vous encourage à faire de même. À la fin de l'article, je suggérerai quelques programmes d'interface graphique que vous pouvez utiliser, mais en général, je ne les utilise que pour aider à visualiser les branches du référentiel..
Comme mentionné précédemment, avec Git, vous ne "consultez" pas une copie de votre plug-in. Vous clonez le référentiel, complétez avec un historique des modifications apportées, ainsi que toutes ses branches et ses balises. L'étape 1 consiste ensuite à cloner le référentiel hébergé WordPress de votre plug-in. Par exemple, je publierai un plug-in 'Post Type Archives Link' basé sur un didacticiel précédent. Ainsi (une fois que vous avez été accepté sur le référentiel WordPress), ouvrez votre interface de ligne de commande et accédez à l'emplacement où vous souhaitez stocker la version locale de votre plug-in. Je vais le mettre dans un dossier appelé 'Plugins'. Une fois là-bas, nous voulons dire à Git où trouver notre plug-in. Au moment de la rédaction de ce document, près de 20 000 plug-ins sont hébergés dans le référentiel WordPress, et plus de 500 000 révisions. Nous ne voulons pas attendre que Git scrute chacun de ceux-ci pour trouver notre plug-in. Donc, tout d’abord, nous trouvons à quelle révision commence notre plug-in (nous voulons que tout son historique). Pour ce faire, nous obtenons le premier journal de votre plug-in (quand il a été ajouté à l'origine au référentiel):
svn log -r 1: HEAD --limit 1 http://plugins.svn.wordpress.org/your-plug-in-name
Il va réfléchir pendant un moment puis vous devriez voir quelque chose comme ceci:
r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (lun. 19 mars 2012) | 1 ligne
Ce premier numéro, "520657" pour mon plug-in, est la première révision. Nous l'utilisons dans la prochaine commande qui indique à Git de cloner l'historique de notre plug-in. Remplacez XXXXXX par votre numéro de révision.
git svn clone -s -rXXXXXX --no-minim-url http://plugins.svn.wordpress.org/your-plug-in-name cd votre nom de plugin git svn chercher git svn rebase
Le '-s'indique à Git de s'attendre à la disposition standard (balise, jonction, branches) d'un référentiel SVN. Le '--no-minimiser-url'arrête la recherche en dehors de votre dossier de plug-in. Assurez-vous qu'il ne manque pas. Si vous le laissez pas, vous risquez de copier tout le référentiel de plug-in WordPress. le -rXXXXXX indique à Git quelle révision rechercher. Si vous laissez cela de côté, Git effectuera une recherche dans l’ensemble de l’historique du référentiel. C'est plus de 500 000 révisions. J'ai laissé ceci une fois et cela a pris environ deux heures. Avec cela, cela ne devrait prendre que quelques minutes.
Une fois que c'est fait, vous devriez trouver qu'il a créé un dossier appelé 'votre-plug-in-name'dans votre dossier' Plugins '. Explorons un peu. Naviguez vers le 'votre-plug-in-name'dossier et lancez une commande pour voir quelles' branches 'existent:
branche git -a
Cela listera toutes les branches, locales et distantes. La seule branche locale doit être maître (l'astérisque indique qu'il s'agit de la branche sur laquelle vous vous trouvez). Les autres branches sont le "tronc" et, le cas échéant, une branche pour chaque tag (SVN considère les tags comme des branches, mais Git est un peu plus intelligent que cela)..
Aller dans votre 'dossier local', 'plugins / nom de votre plugin', vous devriez voir vos fichiers de plug-in (s’il en existait). Avant de créer ou d’éditer des fichiers, nous allons créer une branche distincte sur laquelle travailler..
Mettre à jour: Les commandes ci-dessus ont été mises à jour en raison d'un problème signalé dans les commentaires ci-dessous par Neerav et John Eckman. Le code ci-dessus reflète maintenant la recommandation de Stephen Harris.
L'un des avantages de l'utilisation de Git est que vous pouvez facilement gérer une version de votre plug-in sur GitHub. Cela rend votre plug-in plus accessible aux autres développeurs, qui peuvent suggérer des améliorations ou même apporter leurs propres modifications que vous pourriez intégrer à votre propre référentiel. Si vous avez déjà configuré GitHub, vous pouvez à ce stade vouloir placer votre plug-in sur votre compte. Pour ce faire, créez vous-même un nouveau référentiel sur votre compte GitHub, puis ajoutez-le en tant que branche distante à votre référentiel local:
git remote ajouter l'origine [email protected]:/ .git
'ton nom d'utilisateur'fait référence à votre nom d'utilisateur GitHub et'votre nom de repo'fait référence au nom du référentiel que vous avez créé sur GitHub. Ensuite, il vous suffit de pousser votre référentiel local:
maître d'origine git push
Nous allons créer une nouvelle branche 'travail'. C'est à l'intérieur de cette branche que nous allons modifier notre plug-in, apporter des modifications et ajouter des fonctionnalités, etc. Cela signifie que notre branche "Master" est conservée dans son état d'origine. Cela nous permet de revenir à la branche principale et de la déconnecter à nouveau. En particulier, supposons qu'un bug majeur se trouve dans votre plug-in pendant que vous travaillez sur certaines nouvelles fonctionnalités de votre branche "work". Vous pouvez revenir à votre branche "maître" (qui n'inclut aucune des fonctionnalités sur lesquelles vous travaillez actuellement), valider un correctif pour le bogue puis l'envoyer dans le référentiel WordPress. Vous pouvez ensuite revenir à votre branche de travail et continuer là où vous l'avez laissée. (Remarque: Git ne crée pas de copies de vos fichiers - il n'y aura toujours qu'un seul ensemble de fichiers dans votre dossier local. Le contenu de ces fichiers dépend de la branche sur laquelle vous vous trouvez.)
En fait, c'est une bonne idée de créer une branche pour chaque nouvelle fonctionnalité que vous ajoutez à votre plug-in. Lorsque vous avez terminé, il vous suffit de les fusionner dans la branche principale. Si cela provoque des «conflits», il vous sera demandé de les résoudre manuellement..
Commencez par créer une branche appelée 'work':
travail de branche git
Puis 'check out' (allez à) branche 'travail':
travail de caisse
Un message vous dira que vous êtes passé à la branche "travail". Maintenant, utilisez votre éditeur de texte favori pour ouvrir les fichiers de votre plug-in dans votre dossier local (ou créez-les s'il n'y en a pas encore). Une fois que vous en avez créé quelques-uns, vous voudrez peut-être voir quels fichiers vous avez modifiés. Vous faites cela avec la commande simple:
statut git
Ceci listera les changements de suivi et non suivi des dossiers. Il se peut que certains fichiers ne soient pas gênés par le suivi de Git (tels que des fichiers temporaires), mais si vous avez ajouté de nouveaux fichiers dans le dossier, vous devez dire à Git de les suivre. Vous pouvez le faire avec la commande:
git ajouter
J'ai créé deux fichiers 'post-type-archive-links.php' et 'metabox.js'dans mon dossier local, je les ai donc ajoutées pour dire à Git de les suivre. Vous devez vous assurer que vous suivez votre readme fichier.
Vous pouvez également afficher les modifications depuis votre dernier commit (c’est là qu’un programme graphique devient très pratique)
git diff
Une fois que vous souhaitez valider les modifications dans votre référentiel local:
git commit -a -m "Est-ce que abc to xyz"
fournissant un (détaillé) message des modifications contenues dans le commit.
Lorsque vous apportez des modifications, vous pouvez (et devriez) valider le plus souvent possible - mais de manière logique, de préférence avec un commit pour chaque "chose" que vous faites. Vous devez vous assurer qu'il n'y a pas non plus d'erreur évidente dans vos commits. 'Annuler' un commit est rapide et simple: Pour ce faire, effectuez un autre commit qui annule le précédent:
git revenez HEAD
(Un message vous invitera à décrire cette validation.)
Supposons que vous soyez maintenant dans une position où vous souhaitez appliquer toutes vos modifications au référentiel SVN. Avant de faire cela, nous devons garder à l’esprit quelque chose. Git vous encourage à vous engager souvent, et c'est une bonne pratique de le faire… pour développement. Cependant, votre référentiel de plug-in WordPress est là pour Distribution. Il n'a pas besoin de chaque commit. En fait, ça ne marche vraiment pas vouloir comme le dit Otto (contributeur principal de WordPress):
"Si je vous surprends [en poussant chaque commit séparément], je vous bannirai de WordPress.org. Le SVN n'a besoin que de votre version de travail finale, pas de l'historique complet des centaines de modifications que vous avez effectuées avec Git. Aplatissez vos modifications en un seul commit. "
Pour éviter cela, lorsque nous sommes prêts à transmettre le référentiel WordPress, nous fusionnons tous les commits en un seul. Il y a plusieurs façons de le faire. Nous allons fusionner (et simultanément écraser) nos modifications de notre branche de travail dans notre branche principale. Toutes nos modifications apparaissent alors comme une validation sur la branche principale. Nous supprimons ensuite la branche de travail et poussons la branche principale vers le tronc SVN de notre plug-in.
Tout d'abord, nous voulons revenir à la branche principale:
maître de caisse
Puis écrasez et fusionnez les modifications de branche de travail dans le maître:
git merge --squash work
Si des modifications ont été apportées à la branche principale, il peut y avoir des conflits lors de la fusion. Vous serez invité à résoudre manuellement ces conflits avant la fin de la fusion. Une fois fusionnées, validez les modifications (celle-ci contiendra toutes les validations de notre branche de travail):
git commit -a -m "Modifications apportées a, b, c, d"
Enfin, nous supprimons la branche de travail
branche git - travail
Si vous souhaitez fusionner plusieurs branches, vous pouvez le faire pour chacune d’elles. Il existe des méthodes alternatives, que je ne couvrirai pas, pour aplatir votre historique (comme le rebasage interactif).
À ce stade, vous pouvez, si vous le souhaitez, appliquer vos dernières modifications à votre compte GitHub:
git push -u origine master
Pour accéder au référentiel WordPress, nous devons d’abord nous assurer que notre référentiel local est "à jour":
Git svn rebase
Git ira ensuite chercher votre référentiel de subversion et y fusionnera toutes les modifications que nous venons de faire. Normalement, il ne devrait y avoir aucune modification dans le référentiel WordPress, vous devriez donc voir le message: Le maître de succursale actuel est à jour.
Nous pouvons maintenant appliquer nos modifications au référentiel WordPress
git svn dcommit
Git peut alors vous demander vos identifiants WordPress.org. Une fois entrées, vos modifications seront validées dans le référentiel WordPress. Bientôt, vous devriez recevoir un e-mail du référentiel WordPress, vous informant des commits.
Actuellement, ces modifications resteront dans le coffre. Que faire si nous voulons marquer une nouvelle version de notre plug-in? Lors de la création de la prochaine version de votre plug-in, vous devez avoir mis à jour le fichier Lisez-moi, de sorte que la balise stable pointe vers votre nouvelle version (par exemple, «2.0»). Vous devez également avoir mis à jour les informations d’en-tête de votre plug-in dans votre votre-plug-in-name.php fichier. Si vous avez oublié de le faire, suivez la procédure ci-dessus, après avoir apporté ces modifications.
Une fois que votre 'trunk' est entièrement à jour (y compris les informations de version les plus récentes), il suffit ensuite de créer la nouvelle balise dans le référentiel WordPress:
git svn tag "2.0"
Ceci copie tout dans votre coffre dans tags / 2.0 (ce que vous réalisez normalement avec SVN avec svn cp balises de coffre / 2.0).
Si vous souhaitez marquer la version dans votre référentiel local:
git tag -a 2.0 -m "Marquage 2.0"
Semblable à ce que nous avons fait avec le référentiel WordPress, assurez-vous que nos référentiels concordent, puis envoyez nos modifications et balises:
git pull - origine du maître git push origine du maître git push origine --tags
Enfin, il y a quelques "feuilles de triche" Git qui peuvent être utiles: ici et ici.
Accentsconagua