Recommander la méthode de demande de fusion dans le flux Gitlab
Les branches master et develop ne peuvent pas être poussées directement
maître = production
développer = prochaine version
Lorsqu'il y a de nouvelles exigences, créez une branche d'exigence feature/aaa
Créer une demande de fusion une fois le développement terminé
Fusionner feature/aaa avec la branche develop après la révision du code
Fusionner la branche develop avec master lors de la connexion
Sortie master branche
Pour la question de l'affiche, vous pouvez faire ceci
Créez une nouvelle branche feature/aaa basée sur feature/bbb Après avoir terminé le travail de correction, fusionnez-la dans develop, master puis connectez-vous .
Continuer le développement de feature/aaa et enfin le fusionner dans develop, master
est à peu près une branche master de la branche checkouthotfixes. Écrivez le remède en hotfixes, puis merge en master et develop respectivement. À ce stade, vous pouvez supprimer cette branche hotfixes.
Ensuite développez et améliorez vos fonctions depuis la branche develop, et enfin mettez la branche developmerge vers master en ligne.
Peut-être qu'il existe une meilleure façon, juste pour référence
La stratégie de branche de l'affiche ne nécessite pas de traitement particulier. Elle peut être très bien gérée en suivant le processus normal et en combinant les fonctions de git :
Tout d'abord, continuez à soumettre le code correctif une fois la validation terminée sur le développement pour vous assurer que les fonctionnalités du développement peuvent être publiées et utilisées normalement. La "solution corrective" mentionnée par l'affiche ici fait en fait partie du développement de fonctionnalités et n'est pas considérée comme une correction de bug.
Après cela, vous pouvez entrer dans le processus de publication une fois le test réussi. Si la stratégie de branche d'origine de l'affiche originale inclut une branche de version, vous pouvez créer une branche de version après l'étape précédente et le développement continuera à accepter les soumissions de nouvelles fonctionnalités. Le plan de conception et les solutions temporaires recevront cette fois-ci des corrections de bugs dans la version.
Ce qui précède est en fait un processus normal de développement et de publication. Qu’en est-il du développement ultérieur de la conception et de la suppression des fonctions correctives ? En fait, les développements ultérieurs peuvent en réalité être considérés comme des améliorations ou de nouvelles fonctionnalités, mais simplement comme un développement normal. Vous pouvez annuler la validation de correction d'origine (commande git revert) sur n'importe quel nœud au cours de ce processus d'amélioration, selon vos besoins.
Une fois le remède de retour et la « conception originale » mis en œuvre, il peut être publié selon le processus de publication normal.
D'après ma compréhension, les « fonctions originales » et les « solutions correctives » mentionnées par l'affiche sont des soumissions de code normales. Ce que l'affiche ne sait pas, c'est comment gérer le problème selon lequel la solution de remède temporaire sera finalement abandonnée (annulée), donc l'utilisation de la commande git revert mentionnée ci-dessus devrait satisfaire les attentes de l'affiche. Cela garantit non seulement que toutes les opérations sur la base de code peuvent être enregistrées dans le tronc (maîtriser, développer), mais évite également des problèmes tels que des modèles de branche complexes.
De plus, je ne sais pas si la stratégie de branchement utilisée par l'affiche suit le workflow mentionné par @rsj217. Si develop est la principale branche de développement pour tous les développeurs, je pense qu'il est préférable pour develop de soumettre directement les fonctionnalités inachevées sans les accepter. Dans le travail de développement quotidien, en particulier dans le cas du développement parallèle de plusieurs fonctionnalités/branches, plusieurs branches de fonctionnalités peuvent éviter les interférences les unes avec les autres.
Pour en revenir à la question de l'affiche originale, cette conception inutilisable peut continuer à être développée et ne doit pas être fusionnée dans le développement. Sur la base de cette branche, extrayez une branche de développement pour les fonctionnalités correctives. Une fois les tests terminés, fusionnez-la dans develop pour entrer dans le processus de publication. Les suggestions de fusion et d'annulation suivantes sont toujours nécessaires. Ne violez pas le processus et effectuez un traitement spécial sauf si vous y êtes obligé, et cela conservera toutes les opérations de validation de code.
Il est recommandé de se référer à la branche principale du workflow git master development est utilisé pour la version de développement est utilisé pour publier de nouvelles versions le correctif est utilisé pour corriger les bugs en ligne et autres opérations d'urgence
Disons que votre branche de remède est develop1. Après avoir été mise en ligne, develop1 et master seront fusionnés pour devenir un nouveau master une fois que la branche fonctionnelle d'origine develop sera mature et stable, elle sera fusionnée dans un nouveau master (c'est le cas). très susceptible d'entrer en conflit). Supprimez la partie de develop1 et le test sera mis en ligne sans aucun problème. C'est un peu gênant, et peut-être un peu stupide, mais à chaque fois que git fusionne, un nouveau point est généré vers l'avant. Si vous voulez attendre que le développement se stabilise et restaurer le maître, s'il y a d'autres versions au milieu, le fera. tu perds bientôt quelque chose ?
Il existe peut-être une meilleure façon, juste pour référence
Si vous avez des difficultés à lire Un modèle de branchement Git réussi, vous pouvez lire la traduction de Juven Xu de Un modèle de branchement Git réussi
L'utilisation de git-flow vous aidera. Vous pouvez utiliser des commandes simples pour vous aider à créer et à compléter des branches. Et il existe des flux de travail standardisés pour les versions, les correctifs et les fonctionnalités
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Recommander la méthode de demande de fusion dans le flux Gitlab
Les branches master et develop ne peuvent pas être poussées directement
maître = production
développer = prochaine version
Lorsqu'il y a de nouvelles exigences, créez une branche d'exigence feature/aaa
Créer une demande de fusion
une fois le développement terminé Fusionner
feature/aaaavec la branchedevelopaprès la révision du code Fusionner la branche
developavecmasterlors de la connexion Sortie
masterbranchePour la question de l'affiche, vous pouvez faire ceci
Créez une nouvelle branche
feature/aaabasée surfeature/bbbAprès avoir terminé le travail de correction, fusionnez-la dansdevelop,masterpuis connectez-vous. Continuer le développement de
feature/aaaet enfin le fusionner dansdevelop,masterVous pouvez vous référer au workflow git
est à peu près une branche
masterde la branchecheckouthotfixes. Écrivez le remède enhotfixes, puismergeenmasteretdeveloprespectivement. À ce stade, vous pouvez supprimer cette branchehotfixes.Ensuite développez et améliorez vos fonctions depuis la branche
develop, et enfin mettez la branchedevelopmergeversmasteren ligne.Peut-être qu'il existe une meilleure façon, juste pour référence
Aidez d'abord l'affiche à résoudre ce problème.
La stratégie de branche de l'affiche ne nécessite pas de traitement particulier. Elle peut être très bien gérée en suivant le processus normal et en combinant les fonctions de git :
D'après ma compréhension, les « fonctions originales » et les « solutions correctives » mentionnées par l'affiche sont des soumissions de code normales. Ce que l'affiche ne sait pas, c'est comment gérer le problème selon lequel la solution de remède temporaire sera finalement abandonnée (annulée), donc l'utilisation de la commande git revert mentionnée ci-dessus devrait satisfaire les attentes de l'affiche. Cela garantit non seulement que toutes les opérations sur la base de code peuvent être enregistrées dans le tronc (maîtriser, développer), mais évite également des problèmes tels que des modèles de branche complexes.
De plus, je ne sais pas si la stratégie de branchement utilisée par l'affiche suit le workflow mentionné par @rsj217. Si develop est la principale branche de développement pour tous les développeurs, je pense qu'il est préférable pour develop de soumettre directement les fonctionnalités inachevées sans les accepter. Dans le travail de développement quotidien, en particulier dans le cas du développement parallèle de plusieurs fonctionnalités/branches, plusieurs branches de fonctionnalités peuvent éviter les interférences les unes avec les autres.
Pour en revenir à la question de l'affiche originale, cette conception inutilisable peut continuer à être développée et ne doit pas être fusionnée dans le développement. Sur la base de cette branche, extrayez une branche de développement pour les fonctionnalités correctives. Une fois les tests terminés, fusionnez-la dans develop pour entrer dans le processus de publication. Les suggestions de fusion et d'annulation suivantes sont toujours nécessaires. Ne violez pas le processus et effectuez un traitement spécial sauf si vous y êtes obligé, et cela conservera toutes les opérations de validation de code.
Il est recommandé de se référer à la branche principale du workflow git master development est utilisé pour la version de développement est utilisé pour publier de nouvelles versions le correctif est utilisé pour corriger les bugs en ligne et autres opérations d'urgence
Disons que votre branche de remède est develop1. Après avoir été mise en ligne, develop1 et master seront fusionnés pour devenir un nouveau master une fois que la branche fonctionnelle d'origine develop sera mature et stable, elle sera fusionnée dans un nouveau master (c'est le cas). très susceptible d'entrer en conflit). Supprimez la partie de develop1 et le test sera mis en ligne sans aucun problème. C'est un peu gênant, et peut-être un peu stupide, mais à chaque fois que git fusionne, un nouveau point est généré vers l'avant. Si vous voulez attendre que le développement se stabilise et restaurer le maître, s'il y a d'autres versions au milieu, le fera. tu perds bientôt quelque chose ?
Il existe peut-être une meilleure façon, juste pour référence
Si vous avez des difficultés à lire Un modèle de branchement Git réussi, vous pouvez lire la traduction de Juven Xu de Un modèle de branchement Git réussi
L'utilisation de git-flow vous aidera. Vous pouvez utiliser des commandes simples pour vous aider à créer et à compléter des branches. Et il existe des flux de travail standardisés pour les versions, les correctifs et les fonctionnalités