这种场景下该采用怎么样的git分支管理策略？

Question

目前开发的项目采用git作为版本管理工具， 平时开发有两个分支，develop和master 在develop上开发， 在master发布正式版本。 目前有这样一种情况： 有一个设计好的功能，由于种种原因，在develop分支上开发完成后...

我想大声告诉你 · Answer

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

PHP中文网 · Answer

Vous pouvez vous référer au workflow git

est à peu près une branche master de la branche checkout hotfixes. É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 develop merge vers master en ligne.

Peut-être qu'il existe une meilleure façon, juste pour référence

PHP中文网 · Answer

develop（未开发新功能）-> develop（已开发新功能，新功能不可用）-> develop（继续完善到可用）
                 └───> fix（补救）                                 ╲
                           └───> master（记得在~1版本打 tag 哦）      ╲ merge
           master（tag）<────────────────────────────┘               ↘
                 └───────────────────────────────────────────────> master

phpcn_u1582 · Answer

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 :

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.

怪我咯 · Answer

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

高洛峰 · Answer

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

我想大声告诉你 · Answer

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

巴扎黑 · Answer

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

这种场景下该采用怎么样的git分支管理策略？

répondre à tous(8)je répondrai