Présentation de l'un des modèles de gestion de branche de code GIT

Tutoriel gibLa colonne présente le modèle de gestion des branches de code

Recommandé (gratuit) : Tutoriel gib

C'est comme si les gens étaient dispersés et qu'il était difficile de diriger une équipe. Il existe de nombreuses versions de code et les branches sont difficiles à gérer. Le développement, divers correctifs et autres problèmes entraîneront inévitablement une version. problèmes de gestion des succursales. Aujourd'hui, nous allons jeter un œil à la première solution de gestion de branches de code.

Je tiens à souligner ici que chaque méthode de gestion d'agence a ses propres mérites. Personne n'est forcément meilleur que l'autre, seulement celui qui vous convient le mieux

. Gestion de branche de code populaire et réussie

Cette solution de gestion de branche humaine est dérivée de cet article intitulé Un modèle de branchement Git réussi. De nombreux projets d’entreprise sont gérés de cette manière. L'image ci-dessous couvre ainsi différentes conceptions de branches :

Un modèle de branchement Git réussi

Ce modèle peut essentiellement répondre aux besoins des entreprises ici sont les différentes exigences de gestion des versions de code rencontrées lors du développement du projet. Essayons de décomposer ce modèle pour tout le monde :

Mordre les collines verdoyantes et ne jamais se détendre

Dans l'image ci-dessus, vous pouvez le voir. les noms de deux branches sont en gras :

et

, ces deux-là sont les piliers des branches.

mastermasterdevelop

C'est la première branche après la création d'un nouveau dépôt GIT. Dans ce modèle, la branche master représente la version de la gamme de produits actuelle. Son dernier commit peut être déjà en ligne, ou il peut s'agir d'une fonction qui a été torturée par QA/PD/PO des dizaines de millions de fois et qui peut être en ligne dans. minutes. Autrement dit, cette succursale doit être disponible en ligne à tout moment ! Si quelqu'un soumet une fonction générale à cette version, il risque d'être entraîné au paradis par le PO ! Par conséquent, s'il y a une gestion stricte des autorisations, cette branche sera généralement verrouillée, et seuls les collègues en ligne auront l'autorisation de la déplacer !

De plus, chaque fois que le maître se connecte, une balise sera ajoutée pour indiquer le numéro de version

développer

Généralement, les primates sont impressionnés par des opérations telles que proposer sacrifices au ciel, nous devons donc innover pour faire une grande différence. Afin d'être cohérent avec la force principale, la branche de

est créée sur la base de

C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git branch
* master

C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git checkout -b develop
Switched to a new branch 'develop'

C:\githome\github\gitdou (develop) (gitdou@0.1.0)
λ git show-branch -a --no-name
* [develop] add httpUtil.js
 ! [master] add httpUtil.js
  ! [origin/HEAD] add httpUtil.js
   ! [origin/master] add httpUtil.js
----

develop La sortie de la dernière commande master peut voir que la branche de est créé sur la base de

git show-branch -a --no-namedevelopmasterSi le projet n'est pas particulièrement volumineux et que la gestion des versions est relativement simple, alors les deux branches master et develop suffisent fondamentalement

Style et style s'épanouissent.

---

Lorsque le projet est un peu plus grand, vous rencontrerez diverses exigences en matière de gestion de versions, mais vous n'aurez peut-être pas besoin de toutes. Vous pouvez créer ces branches en cas de besoin, comme. Il existe des

,

,

featuresreleasehotfixfonctionnalités

La première situation est plus courante. Il y a de nombreux collègues qui développent le projet en parallèle, comme la division de plusieurs. modules en plusieurs Si l'équipe développe, si chaque module est lancé sur la branche

, alors il n'y a fondamentalement aucun moyen de faire une intégration continue (Continuer l'intégration). Bien que les modules s'entendront certainement harmonieusement lors de l'intégration finale, pendant le processus de développement, tous les commits ne sont pas nécessairement compatibles avec le module, il est donc préférable de faire fonctionner chaque module dans un coin seul, puis il est préférable d'être sûr que cela peut être égalé. Si nous tombons amoureux, retrouvons-nous.

C'est ici que nous pouvons créer diverses develop branches basées sur des modules. Les développeurs concernés peuvent développer sur les branches correspondantes. Lorsque chaque branche fonctionnelle est pratiquement terminée, nous fusionnerons ces branches dans Go to <.>

S'il existe une branche de fonctionnalités, alors la branche de développement deviendra essentiellement une branche d'intégration feature

version

Comme mentionné précédemment, la branche master représente la version de la gamme de produits actuelle, qui peut être déployée en ligne en quelques minutes sans finir comme un sacrifice au ciel. Cependant, certains projets ou équipes rencontrent une telle situation. Avant que le produit ne soit mis en ligne, il doit être déployé sur 准产品线 et joué en interne pendant environ une semaine. Après s'être assuré qu'il n'y a aucun problème. peut être mis sur la gamme de produits. Pendant la semaine de tests internes, si vous rencontrez un problème, corrigez-le rapidement depuis la branche de développement, puis rendez-vous sur 准产品线 pour vérification. Si nous utilisons la branche master pour déployer une quasi-gamme de produits et découvrons un problème au cours de la semaine de tests internes, et qu'il y a des problèmes urgents à résoudre sur notre gamme de produits à ce moment-là, alors nous ne pouvons pas prendre directement la branche master et allez en ligne. Ceci est Impossible de tenir notre promesse précédente : master分分钟可以上线而不用祭天

Nous pouvons donc créer une branche de publication pour déployer la gamme de quasi-produits et résoudre les problèmes une fois que nous avons confirmé qu'il n'y a aucun problème. , nous pouvons ensuite synchroniser avec la branche master En ligne

hotfix

Comment un développeur système peut-il être exempt de bugs ! Lorsqu'un bug 无辜 apparaît sur la gamme de produits, vers quelle succursale doit-on s'adresser pour le corriger ?

• master : Évidemment inapproprié. S'il y a des bugs sur la gamme de produits en raison de la conception ou d'une mauvaise considération, il n'est généralement pas nécessaire de sacrifier. Cependant, si vous effectuez des modifications aléatoires sur le master à cause de cela. , vous devrez peut-être sacrifier au ciel
• sortie : ceci est pour la prochaine version. S'il s'agit de la version précédente, les nouvelles modifications détruiront la signification du numéro de version d'origine. Par exemple, la branche d'origine s'appelait release-1.0.1, donc après avoir ajouté cette version, sera-t-elle toujours appelée par ce nom ?
• développeur : S'il y a d'autres fonctionnalités en cours de développement, celles-ci seront incluses dès leur mise en ligne !
• fonctionnalité : C'est un peu tiré par les cheveux

Il semble que les quatre branches ci-dessus ne conviennent pas, alors trouvons-en une nouvelle, appelée la branche hotfix. vient de La branche master est créée directement et est utilisée pour effectuer des réparations urgentes de code sur la gamme de produits, ou pour ajouter temporairement de petites fonctions. Les développeurs développent directement sur cette branche. Une fois la fonction terminée, ils se rendent directement sur la branche principale et se connectent.

N'oubliez pas de synchroniser les fonctions avec le développeur à chaque lancement du correctif, puis avec les branches de chaque fonctionnalité

---

Ce qui précède concerne celui-ci 成功的代码分支管理模型 L'explication peut essentiellement répondre aux besoins de gestion des versions de code de la plupart des projets dans la plupart des entreprises ! Nous présenterons plus tard un autre modèle de gestion de branche de code, qui fait référence à une méthode de gestion de notre entreprise. À la prochaine fois !

Si vous souhaitez en savoir plus sur la programmation, faites attention à la rubrique formation php !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!