Bonne façon d'utiliser Git / GitHub - PHP System with Dev / Testing / Production servers
Je m'excuse si c'est évident ou facile, j'ai regardé un bon nombre de tutoriels git/github et lu d'autres articles, mais je veux m'assurer que ce que je fais est bien.
Je veux incorporer VC (pour des raisons évidentes) dans mon équipe et processus de développement.
Processus de développement actuel (avec Dreamweaver):
* Recevez un ticket (ou un bon de travail)
* Télécharger le fichier sur le serveur de développement
* Modifiez le fichier
* Transférer le fichier sur le serveur de développement
* Modifications testées/vérifiées
* Envoyer au serveur de production
J'essaie de comprendre comment faire notre nouveau processus de développement avec Git.
Je passe à PHPStorm (qui est un réel PHP IDE avec intégration directe avec Git).
Serait-ce quelque chose comme
- Recevez un ticket (ou un bon de travail)
- Commander/mettre à jour/télécharger le (s) fichier (s)
- Changer les fichiers
- Téléchargez le fichier (qui je suppose est également le répertoire de travail actuel ...?)
- À la fin de la journée, faites un commit
- Demander au script de génération d'envoyer des données au serveur de test (génération nocturne)
Ou serait-il préférable de faire quelque chose comme
- Recevez un ticket (ou un bon de travail)
- Commander/mettre à jour/télécharger le (s) fichier (s)
- Changer les fichiers
- Télécharger le fichier/valider
- Demander au script de génération d'envoyer des données au serveur de test (génération nocturne)
Ou existe-t-il un autre moyen? Vous avez un peu de mal à comprendre quel serait le débit optimal?
Toute aide serait grandement appréciée.
Modifier
J'essaie de voir s'il est préférable d'avoir une version du serveur localement (tous les développeurs), et si oui, comment cela fonctionne-t-il si vous avez environ 7 branches?
Sinon, comment gérez-vous environ 7 succursales avec elles sur le Web? Utilisez-vous des fichiers FTP ou utilisez-vous des crochets Git pour les mettre à jour automatiquement?
Mise à jour 26/07/2012
Après avoir travaillé avec Git pendant un bon moment maintenant, j'ai suivi ce modèle de branchement avec beaucoup de succès: n modèle de branchement Git réussi
La réponse à ce qui précède était oui - devrait certainement avoir une version locale du serveur.
En supposant que vous ayez un serveur en direct et un serveur de développement, je ferais quelque chose dans ce sens.
Avant même de commencer un cycle de développement, j'aurais au moins deux branches:
- Master - le serveur de développement fonctionne sur cette branche
- Stable - le serveur en direct fonctionne sur cette branche.
Donc, si un développeur obtient un ticket ou un bon de travail, il/elle effectuera les actions suivantes:
- git pull Origin master
- git branch featureBranch (nommé comme l'ID du ticket ou comme une bonne description de l'ordre de travail)
- fonctionnalité de paiement git
- Apportez des modifications qui accompliront le changement souhaité. Engagez-vous aussi souvent que nécessaire. Faites cela parce que vous allez créer une histoire précieuse. Par exemple, vous pouvez essayer une approche d'un problème et s'il ne fonctionne pas, l'abandonner. Si un jour plus tard vous voyez la lumière et souhaitez réappliquer la solution, c'est dans votre histoire!
- Lorsque la fonctionnalité est entièrement développée et testée localement, checkout master.
- fonction de fusion gitBranch
- git Push Origin master
- Testez les modifications apportées sur votre serveur de développement. C'est le moment d'exécuter tous les tests auxquels vous pouvez penser.
- Si tout fonctionne, fusionnez la fonction ou corrigez-la dans la branche stable. Maintenant, le changement est en direct pour vos clients.
Récupération du code sur le serveur
La mise à jour des serveurs ne devrait pas être un problème. Fondamentalement, je les configurerais en tant qu'utilisateurs, tout comme vos développeurs. Dans mon entreprise, nous avons configuré les serveurs en tant qu'utilisateurs en lecture seule. Fondamentalement, cela signifie que les serveurs ne peuvent jamais pousser quoi que ce soit mais peuvent toujours tirer. Cependant, la configuration n'est pas triviale, vous pouvez donc tout aussi bien créer une interface Web simple qui ne permet qu'un tirage git. Si vous pouvez empêcher vos développeurs de faire des choses sur des implémentations en direct, vous êtes en sécurité :)
[ÉDITER]
En réponse aux dernières questions posées dans les commentaires de cette réaction:
Je ne sais pas si je comprends bien votre question, mais en gros (un peu simplifié), c'est comme ça que je ferais, si j'étais à votre place. 
La machine de test (ou la racine Web qui agit comme une implémentation de test) a son code source basé dans un référentiel git avec la branche principale extraite. Lors de la création de ce référentiel, vous pouvez même supprimer toutes les autres références à toutes les autres branches afin de vous assurer que personne ne peut extraire une mauvaise branche dans ce référentiel. Donc, fondamentalement, la machine de test a un référentiel Git avec uniquement une branche principale qui est extraite.
Pour les serveurs en direct, je ferais exactement la même chose, mais cette fois avec la branche stable vérifiée. Le développeur doit avoir un référentiel local cloné dans lequel toutes les branches existent. Et une implémentation locale du logiciel que vous construisez. Ce logiciel tire sa source d'un référentiel git local. En d'autres termes: à partir de la branche actuellement extraite de ce référentiel.
Codage réel
Lorsqu'une nouvelle fonction est souhaitée, une branche de fonction locale peut être créée sur la base du maître actuel. Lorsque la branche est extraite, les modifications peuvent être apportées et vérifiées localement par le développeur (puisque le logiciel s'exécute maintenant sur la source de la branche de fonctionnalité).
Si tout semble être en ordre, les modifications sont fusionnées de la branche de fonctionnalité au master et transmises à votre "machine git". "votre github" pour ainsi dire. Les tests peuvent désormais extraire les modifications afin que tous les tests nécessaires puissent être effectués par le contrôle qualité. S'ils décident que tout va bien, le développeur peut fusionner les modifications de master en stable et pousser à nouveau.
Il ne reste plus qu'à tirer de vos machines en direct.