Après avoir examiné plusieurs workflows git, j'estime qu'aucun d'entre eux n'est conforme à mon processus actuel. Actuellement, nous disposons de trois environnements : environnement de production, environnement de test et environnement local. Les développeurs développent localement, poussent vers l'environnement de test, et les testeurs testent et acceptent dans l'environnement de test.
À l'heure actuelle, nous n'avons qu'une petite équipe de plus d'une douzaine de personnes. Nous n'avons pas de processus de publication de version spécifique, nous n'avons donc pas de version spécifique à publier un certain jour ou de tâche à accomplir. à quelle heure. Le travail de chacun ressemble plus à un Hotfix, après avoir terminé une petite fonction ou corrigé un petit bug, poussez-le directement vers la branche de développement. La tâche est dirigée vers le testeur pour tester l'environnement de test. fusionnez directement le développement dans le maître et publiez-le ! Ce processus est correct lorsqu'il y a peu de monde. S'il y a un peu plus de monde, cela impliquera que j'ai une fonction qui est en ligne et qu'une autre fonction est encore en phase de test. Master et development ne peuvent pas être fusionnés, et je peux. attendez seulement la fin du test...
Sur la base du modèle de branche de fonction, il semble que les problèmes ci-dessus puissent être résolus. Coupez une branche pour exécuter des fonctions ou corriger des bogues, fusionnez-la dans le développement pour les tests et fusionnez-la dans le maître après avoir réussi le test. temps, le maître peut être poussé vers l’environnement de production à tout moment. Mais un autre problème est que le niveau des membres de l'équipe est inégal. Tout le monde ne peut pas être autorisé à fusionner avec le maître. En d'autres termes, l'opération de fusion avec le maître ne peut être effectuée que par un ou plusieurs. peu de personnes. Pas toutes, mais il peut y avoir de nombreuses branches générées chaque jour. Même la modification d'une ligne de texte peut être une branche. La fusion manuelle de ces petites branches est une charge de travail énorme. C'est un peu similaire à la façon de soumettre un PR, mais. ce n'est pas suffisant....
Existe-t-il un moyen de permettre aux testeurs de voir vos modifications à temps pour les tests, à tout moment et n'importe où ! Soyez sélectif ! Fusionner le code dans l'environnement de production ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
C'est très similaire à notre workflow, mais nous avons stipulé une heure précise pour publier la version. Une fois la version publiée, les développeurs développeront sur leurs propres branches, puis lors de la fusion, ils enverront une demande de fusion. au superviseur, et le superviseur l'acceptera, puis testera également le développement. Après le test, s'il n'y a pas de problème, accédez à la branche principale.
Je pense que votre question est normale. Par exemple, si A crée une fonction, il doit la tester lui-même et il n'y a aucun problème avant de pouvoir pousser la branche de développement puis tester si la fonction globale est complète, peu importe qui la publie. cette version, il doit passer par ce processus. S'il y a un code en cours de test lors du développement, mais qu'il y a une correction de bogue urgente à pousser, il existe généralement deux méthodes : l'une consiste à sélectionner le code testé lors du développement et l'autre consiste à utiliser la branche d'urgence.
git Cherry-pick
Cette commande peut fusionner sélectivement les commits. Pour les tests de notification, vous pouvez configurer GitHub pour envoyer automatiquement des e-mails à l'adresse e-mail spécifiée après la fusion.
git cerise-pick