Débuter avec Subversion, Git ou un système de contrôle de version similaire pour conserver l’historique de mes fichiers?
Je me rends bien compte que cette question peut sembler complexe, mais je recherche des exemples spécifiques de configurations/flux de travail que les utilisateurs utilisent pour conserver l'historique des versions des fichiers modifiés sur un site WordPress. Par exemple, lors du développement d'un site (et même après sa mise en ligne), j'apporte souvent des modifications aux fichiers CSS et PHP, mais je ne dispose pas d'un excellent moyen de revenir aux anciennes versions de ces fichiers. Pour mes besoins, apporter des modifications à une installation de développement local, puis les copier sur le site actif pose souvent plus de problèmes que je ne le souhaiterais. Des suggestions sur la façon de commencer à utiliser un outil de gestion de versions pour suivre les modifications apportées aux fichiers sur un site actif?
Je ne sais pas à quel point vous savez utiliser le contrôle de version, mais je suis récemment passé de SVN à GIT et je trouve ça génial!
Bien que cela dépende du serveur de votre site live, GIT est installé (ou vous le permet). J'ai aussi une configuration GIT sur le serveur live, exécutant une branche appelée quelque chose comme production. Chaque fois que je finis d'implémenter/réparer quelque chose localement, je le fusionne dans la branche production, puis SSH dans le serveur du site actif et récupère les modifications. Battements de fichiers par FTP lorsque vous ne savez jamais si vous écrasez les modifications, etc.
Je recommanderais de mettre un peu de temps à se familiariser avec GIT (si vous ne l'avez pas déjà fait), je trouve cela beaucoup plus facile et moins compliqué que SVN lorsqu'il s'agit de modifier/ajouter des charges de fichiers (et contrairement à SVN, cela ne met pas stupide .svn folder partout ).
Alors:
Bien sûr, je suis sur un Mac, donc désolé si aucune de ces choses ne s'applique.
Éditeur de code: Coda GIT installé via des ports (avec Porticus) Git: GitX
Si je devais tout mettre en place un nouveau, je ferais:
Installer Coda
Installez Porticus (ce qui vous obligera à installer Ports, mais cette page contient des informations)
Une fois que vous avez installé Porticus, ouvrez-le ouvert, recherchez "git-core" et installez-le.
Téléchargez et installez GitX 7-5
Il existe un bon guide sur la mise en place d'un dépôt git ici , mais en quelques mots: 1. Ouvrez Terminal. 2.
cdoù vous voulez que votre site réside.$: mkdir mysite && cd mysite3.$: git initet c'est tout! Si vous ajoutez des fichiers à ce dossier, passez à l'étape suivante.Une fois que vous avez configuré un référentiel GIT localement (article ci-dessus), si vous ouvrez ce répertoire dans GitX, vous serez en mesure de valider des éléments, etc.
Tout installer sur le serveur peut être un peu délicat, j'ai un compte MediaTemple et un compte Dreamhost qui ont tous deux GIT prêt à l'emploi. Le lien en 5. vous indique comment ajouter un dépôt à distance. Ne le faites pas jusqu'à ce que vous souhaitiez intégrer votre site actif à l'équation. Je recommanderais que tout fonctionne localement en premier (contrairement à SVN, GIT ne nécessite pas de référentiel distant, vous pouvez donc tout sauvegarder sur votre ordinateur pour le moment).
J'utilise SVN pour le contrôle de version avec everything je le fais dans le développement WordPress. En fait, j’ai commencé comme ça parce que j’avais besoin de SVN pour le développement de plug-ins ... une fois que j’y ai commencé, c’était une extension naturelle de continuer à utiliser SVN pour les thèmes et les scripts personnalisés sur les sites clients.
Plug-ins
Étant donné que les plug-ins sont déjà hébergés sur le serveur WordPress, je viens juste d'extraire un plug-in directement dans le répertoire /wp-content/plugins/ de mon installation WordPress locale (j'utilise WAMP sur ma zone de développement). Ensuite, j'apporte des modifications à ma copie locale et, lorsqu'elle est prête pour showtime, je m'engage dans le référentiel. C'est un processus sans heurts, sans téléchargement/téléchargement et une vérification instantanée du bon fonctionnement de mes modifications.
Des thèmes
Les thèmes sont un peu différents, en particulier lors de la création pour un client. Je crée un référentiel local (j'ai une partition R sur mon disque dur spécialement à cet effet) et extrait le référentiel vide directement dans mon répertoire /wp-content/themes. Ensuite, j'apporte les modifications nécessaires et développe jusqu'à ce que tout soit prêt, en validant les modifications au fur et à mesure.
Lorsque je suis prêt à publier le thème sur le serveur de production d'un client, j'exporte le référentiel, le compresse et utilise le thème natif >> Ajouter une nouvelle fonctionnalité dans WordPress. Cela fonctionne également avec les plug-ins personnalisés (qui ne sont pas hébergés par WordPress).
Outils
Comme je l'ai dit, j'utilise WAMP sur ma machine locale pour exécuter une installation de développement de WordPress. Cela fonctionne parfaitement sur ma boîte et me permet d'exécuter autant d'instances de WordPress que nécessaire pour un projet particulier.
Pour SVN, j'utilise Tortoise SVN . C'est gratuit, remarquablement facile à utiliser et s'intègre à la structure de fichiers et de commandes de Windows. La mise à jour, la validation et l'exportation sont toutes simples, faites un clic droit et sélectionnez des opérations de commande. Utiliser "Exporter" vous permet d’envoyer le dossier entier (sans les ennuyeux dossiers .svn) directement vers n’importe quel emplacement de votre choix - j’exporte souvent sur le bureau. Vous pouvez également cliquer avec le bouton droit de la souris sur le dossier. WordPress gère le téléchargement.
Le transfert manuel de fichiers peut s'avérer fastidieux, en particulier si vous continuez à modifier un fichier mais pas tous. Si vous utilisez plutôt FTP sur tout le répertoire avec l'option "écraser tout", il est beaucoup plus facile de remplacer les anciens fichiers (et vous n'avez pas besoin de savoir quels fichiers ont été modifiés ou non). C'est comme l'ancienne installation de 5 minutes de WordPress - il suffit de tout remplacer par la nouvelle version.
Personnellement, je pense que c'est un exercice amusant d'installer SVN/GIT et de le gérer, mais si vous pouvez vous en servir pour 15 dollars par mois, Beanstalk vaut chaque centime. Ils gèrent tout le serveur pour vous. http://beanstalkapp.com/ Les outils de déploiement FTP sont géniaux. Mine déploie automatiquement la version sur mon serveur de transfert lorsque je commets par exemple
Un autre moyen d'obtenir un versioning de fichier personnel consiste à utiliser la liste déroulante. Chaque fois que vous enregistrez un fichier dans votre liste déroulante, il en suit la version et vous pouvez restaurer ultérieurement toute version précédente. Vous et un autre développeur, ou un groupe, pouvez partager un dossier de boîte déroulante. Certes, cela ne concerne pas les liaisons, les fusions, etc., mais il est très facile pour une équipe distribuée de travailler sur un seul site Web. Vous ne pouvez pas vraiment travailler sur les mêmes fichiers à la fois.
Nous conservons notre copie de travail SVN dans une boîte de dépôt, puis je valide les fichiers au moment de l'écriture. Mes concepteurs ne commettront pas de fichiers et ne traiteront pas avec SVN. C’est donc le compromis.
Je préfère SVN parce que je n'ai pas besoin de toutes les liaisons pour lesquelles GIT est si génial et il existe de meilleurs outils d'interface graphique disponibles de SVN.
J'aime Aptana beaucoup, il a Subversion intégré et vous pouvez vous connecter à votre serveur avec ftp/sftp facilement et Push fichiers, une autre grande fonctionnalité qui existe est que si vous créez un nouveau projet php et incluez le "entier" dossier WordPress (avec wp-admin, wp-includes) vous obtenez la complétion de code dans vos fichiers de thème.
Dans ma configuration, le repo est local.
Vous demandez "mais je recherche des exemples spécifiques de configurations/workflows que les gens utilisent pour conserver l'historique des versions des fichiers modifiés sur un site WordPress", mais vous mentionnez également des produits :)
Vous obtenez ci-dessus une liste d’outils et de bonnes pratiques, mais je vais me concentrer ici sur les flux de travail: ILS NE SONT PAS SPÉCIFIQUES À WORDPRESS:
Mais pour les exemples généraux/setups/workflows:
Pour commencer: il existe des modèles CM, donc indépendants de l'outillage. Google sur CM Patterns, beaucoup de livres, même les communautés de wiki, par exemple. http://www.cmcrossroads.com/forums .
Il existe également des guides sur la configuration d'une stratégie de flux valide (stratégie de flux Google), etc.
Je ne pense pas que les déploiements WordPress aient quelque chose de spécial par rapport à CM Management, y compris le développement parallèle distribué sur de grandes usines Siebel, SAP, Informatica, Java, etc. C'est vraiment presque défaut.
Ce qui manque, je pense, c’est que personne n’a écrit (encore) un CMplan pour le développement WordPress (IEEE). Une fois que quelqu'un a fait cela (outil indépendant). Je pense que les exigences peuvent être remplies avec n’importe quel outil.
Je pense que la raison pour laquelle ce plan n’a pas été écrit est que presque toutes les implémentations WordPress sont toujours effectuées par une seule personne avec une configuration de développement/production simple. Il n’est donc pas nécessaire que plusieurs développeurs/concepteurs soient en phase de construction pour déployer différentes versions exécutées dans le logiciel. environnement de test, par exemple.
le plan CMP commence par l'identification de tous les CI, autrement dit: faites une liste de tous les types de CI présents dans une implémentation WordPress, y compris les applications, plugins, base de données, documentation, aide, contenu, fichiers de configuration, notes de publication (!), etc. ..). C'est un bon début. Ensuite, décidez ceux que vous souhaitez inclure dans CM.
Décidez ensuite quelles sont les causes des changements sur ces CI, par exemple. un appel client pour un correctif, ou une mise à niveau nécessaire. Si cela est fait correctement, cela conduit à une situation dans laquelle vous avez le sentiment que tout est sous contrôle.
Des décisions telles que la fusion de la production au développement et la façon de gérer cela fait partie de ce chapitre (2 modèles principaux ici) (bien que vous deviez bien sûr essayer de minimiser ces correctifs).
Ce n’est que plus tard que vous chercherez un outil permettant de gérer CM d’un côté (qui inclut la gestion des versions comme l’un des outils) et l’outil de gestion des modifications de l’autre (ce qui vous permet de rester sain d’esprit).
Je pense que c'est le meilleur flux de travail pour commencer car, pour autant que j'ai googlé, personne ne l'a encore fait. Je pense qu'une fois que la première personne a écrit un plan WordPress CM (selon IEEE), une autre personne WordPress dans le monde peut copier ce plan, procéder à des ajustements et mettre en œuvre les modèles de son outillage.
N'est-ce pas trop de travail/trop lourd: cela dépend si vous avez une entreprise ou non: cela peut vous faire économiser beaucoup de temps un jour d'avoir un bon plan de CM.
Je suis sur un hôte partagé, je ne peux donc pas installer SVN ou quoi que ce soit du genre. J'utilise Mercurial pour le contrôle de version sur ma machine personnelle. J'utilise la synchronisation FTP de Beyond Compare pour maintenir les dossiers locaux et distants synchronisés.
j'utilise git. c'est simple. vous devez seulement comprendre une commande simple telle que cloner, comiter, pousser, tirer et vous êtes prêt à partir. c'est la base.
même si vous utilisez plutôt git, par exemple pour coordonner une équipe afin de travailler sur un produit, il s'agit d'un autre niveau. mais au final, cela valait la peine d’utiliser git ou n’importe quel contrôle de version. il y a de vrais chances quand la merde arrive.