Un modèle de réussite des succursales à Git

Pour utiliser le Git est important, et cela inclut la maintenance d’un environnement de développement collaboratif pour les logiciels gérable.

Crédits

Ce post est une version portugaise de l’original, En anglais, “Un modèle de branchement Git réussi“, dûment autorisé par l’auteur, Vincent Driessen. Merci l’homme!

Pour des raisons techniques, certains mots-clés ont été délibérément conservés en anglais. J’ai essayé d’assurer l’originalité du texte, mais j’avoue que j’ai dû faire des ajustements pour faciliter la compréhension dans notre langue (EN-BR). Toute correction ou suggestion d’amélioration de la traduction est la bienvenue.

Introduction

Ce n’est pas un post enseignant comment utiliser Git. Si c’est ce dont vous avez besoin, suggèrent de jeter un oeil à la Manuel do Git. Ce n’est pas non plus notre objectif de montrer comment faire une version logicielle, dans ce cas, Regardez Version sémantique.

Ici, la proposition est de gérer la collaboration de l’équipe dans la version logicielle. Vous savez quand vous avez plusieurs programmeurs “Remuant” dans le même code source? Ceci est important pour accélérer le développement des, mais il peut générer beaucoup de maux de tête (blessures et retravailler) s’il n’y a pas de contrôle. Empêcher un développeur de surécrire le travail d’un autre et d’assurer un développement progressif et organisé, minimiser les conflits et gérer les versions logicielles, est que nous utilisons Git et le Branches puis.

Modèle de branches

Dans ce post, je présente le modèle de développement que j’ai utilisé dans certains de mes projets (au travail et en privé) Sur 1 Ans, et qui a été très réussie. J’ai voulu écrire à ce sujet pendant une longue période, mais n’a jamais trouvé de temps disponible, jusqu’à présent. Je ne vais pas parler des détails du projet, à peu près les stratégies de Branches et la gestion des Versions.

Ce modèle se concentre exclusivement sur Git comme un outil pour la version de l’ensemble de notre code source. (D'ailleurs, si vous êtes intéressé par git, notre entreprise Gitprime Fournit, en temps réel, quelques analyses de données étonnantes pour l’optimisation de l’ingénierie logicielle)

Pourquoi git?

Pour une discussion approfondie des avantages et des inconvénients de git par rapport aux systèmes centralisés de contrôle des sources, Regardez un Web. Il y a une énorme “Guerre” autour de cela. En tant que développeur, Je préfère Git à tous les autres outils existants aujourd’hui. Git a sans aucun doute changé la façon dont les développeurs pensent à faire un Fusion ou créer un Direction générale de la. Je viens du monde classique de CVS/Subversion, où fusion/branchement c’est quelque chose que vous ne faites que de temps en temps et toujours sembler un peu effrayant (“Méfiez-vous des conflits de Fusion, ils vous mordent!”).

Avec Git ces actions [fusion/branchement] sont extrêmement simples et représentent l’une des principales parties de notre routine de travail, crois. Par exemple, dans Livre CSV/Subversion, Branchement et Fusion sont abordés pour la première fois seulement dans les chapitres suivants (pour les utilisateurs avancés), tandis que dans n’importe quel livre sur Git, cela est vu dans le chapitre 3 (Base).

En raison de sa simplicité et de sa nature répétitive, Branchement et Fusion ne sont plus quelque chose à craindre de. En réalité, les outils de contrôle de version devraient aider àFusion et créer Direction générale de la plus que toute autre chose.

Plus de parler, passons au modèle de développement. Le modèle que je vais présenter ici n’est essentiellement rien de plus qu’un ensemble de procédures que chaque membre de l’équipe doit suivre afin de trouver un processus de développement de logiciels gérés.

Décentralisée, mais centralisé

La configuration du référentiel que nous utilisons et qui fonctionne très bien avec ce modèle de Branchement est composé d’un référentiel central. Notez que ce référentiel est uniquement “considéré comme considéré comme” Centrale (parce que Git est un DVCS [Systèmes de contrôle de version distribués], ie, il n’y a rien de tel qu’un référentiel central au niveau technique). Nous ferons référence à ce référentiel Origine, puisque ce nom est familier à tous les utilisateurs git.

Chaque développeur Tire et Pousse pour le Origine. Mais au-delà de la relation push-pull pour la centrale [Origine], chaque développeur peut également [Tirer] les changements d’autres paires pour former des sous-équipes. Par exemple, cela peut être utile de travailler avec deux développeurs ou plus sur une grande nouvelle fonctionnalité, envoi préalable [Poussant] les travaux en cours pour le Origine. Dans la figure ci-dessus, il ya des sous-téams Alice et Bob, Alice et David, et Clair et David.

Techniquement, cela signifie rien de plus qu’Alice a défini un Git à distance appelé Bob, pointant vers le référentiel de Bob, et vice versa.

Les principales branches

En arrière-plan, ce modèle de développement est très inspiré par les modèles existants là-bas. Le référentiel central dispose de deux branches [Branches] avec une vie infinie:

  • maître
  • développer

Le maître de branche dans Origine doit être familier à tous les utilisateurs de Git. Parallèlement à maître de branche, il ya un autre Direction générale de la Appelé développer.

Considérer origine/maître comme étant la branche principale où le code source de Tête reflète toujours un État prêt à la production [prêt pour la production].

Considérer origine/développement comme étant le Direction générale de la où le code source de Tête reflète toujours un état avec les derniers changements de développement à apporter dans la prochaine version. Certains appelleraient cela “Direction générale de la Intégration”. C’est là que les bâtiments les plus sinistres se produisent.

Lorsque le code source du branche développer atteint un point stable et est prêt à être libéré [Libéré], toutes les modifications doivent être fusionnées [Fusionné] retour à la maître de branche puis marqué avec un numéro de version [Communiqué de]. Comment cela se fait en détail, sera discuté plus tard.

Alors, chaque fois que les modifications sont incorporées [Fusionné] retour à la maître, une nouvelle version est générée [Libéré], par définition. Nous essayons d’être très stricts à ce sujet, Alors, Théoriquement, nous pourrions même utiliser un script Crochet pour créer et envoyer automatiquement notre application aux serveurs de production chaque fois qu’il y a un Commettre dans maître.

Branches auxiliaires

À côté de la Branches Principal, maître et développer, notre modèle de développement utilise une variété de Branches soutien pour aider au développement simultané parmi les membres de l’équipe, Ce qui 1) facilite la suivi des nouvelles fonctionnalités [fonctionnalités], 2) prépare la livraison d’une nouvelle version [Communiqué de] et 3) vous aide à corriger rapidement les défaillances de production [Correctif]. Contrairement aux Branches Principal, Ces Branches a une courte durée de vie, puisqu’ils finiront par être retirés.

Les différents types de Branches [Auxiliaire] que nous pouvons utiliser, sont:

  • Branches de fonction
  • Branches de libération
  • Branches de correctif

Chacune de ces Branches a un but spécifique et est lié par des règles strictes, Et alors, Branches peut donner lieu à Direction générale de la et que Branches doit être fusionné [Fusionné] à leurs cibles. Nous allons voir chacun d’entre eux [Branches] en un instant.

D’un point de vue technique, Ces Branches ne sont pas considérés “Spécial”. Chaque type de Direction générale de la est classé par la façon dont nous les utilisons. En tout cas, sont tout simplement simples Branches du bon vieux Git.

Branches de fonction

[Caractéristiques = caractéristiques/fonctionnalités]

– Il peut ramifier [Direction générale de la] De:
développer
– Doit fusionner [Fusion] encore une fois le:
développer
– convention pour la nomination de la Direction générale de la:
N’importe quoi, Sauf maître, développer, release-*, ou ou correctif-*

Lla branches de fonctionnalité (ou parfois appelé sections thématiques) sont utilisés pour développer de nouvelles fonctionnalités pour une version proche ou future. Lors du démarrage de l’élaboration d’un Fonction, la version cible dans laquelle cette fonctionnalité sera incorporée peut bien être inconnue à ce moment-là.

L’essence d’un branches de fonctionnalité est qu’il existe tant que le Fonction est en développement, mais finalement, il sera incorporé [Fusionné] retour à la développer (pour ajouter définitivement le nouveau Fonction à la prochaine Communiqué de) ou jetés (dans le cas d’une expérience infructueuse).

Branches de fonction existent généralement uniquement dans le référentiel développer, pas dans Origine.

Création d’une branche de fonctionnalité

$ git checkout -b développer la myfeature
# Switched to a new branch "myfeature"

L’intégration d’une fonctionnalité finie dans le développement

fonctionnalités fini peut être fusionné[Fusionné] avec le branche développer pour certainement les ajouter à la prochaine Communiqué de.

$ git checkout développer
# Passé à la branche 'développer'
$ git fusionner --dans-ff myfeature
# Mise à jour ea1b82a.. 05e9557
# (Résumé des changements)
# $ git branche -d myfeature
# Branche myfeature supprimée (était 05e9557).
$ git pousser origine développer

Le drapeau –no-ff provoque la fusion [Fusion] toujours créer un nouvel objet de Commettre, même si la fusion pouvait être effectuée avec un avance rapide [Ff]. Cela empêche la perte d’informations sur l’histoire de l’existence d’un branche de fonctionnalité, groupement tous les Sur qui ont été ajoutés à la Fonction. Comparer:

Dans ce dernier cas, [à partir de la figure ci-dessus], il est impossible de voir de l’histoire git qui de la Sur ont été mis en œuvre dans le cadre d’un Fonction; vous auriez à lire manuellement tous les messages journaux. Inverser un Fonction Toute (ie, un groupe de Sur), c’est un vrai casse-tête dans la dernière situation, alors qu’il est facile à faire si le drapeau –no-ff a été utilisé.

Oui, cela va créer un peu plus d’objets de Sur (Vide), mais le gain est beaucoup plus élevé que le coût.

Branches de libération

[Version = version/livraison/version]

– Il peut ramifier [Direction générale de la] De:
développer
– Doit fusionner [Fusion] encore une fois le:
développer et maître
– convention pour la nomination de la Direction générale de la:
release-*

Lla libère des succursales aider à préparer une nouvelle version de production [sortie de production]. Ils vous permettent de mettre les gouttes sur la dernière minute i. De plus,, ils permettent des corrections mineures de Insectes et la définition de méta-données Fora Communiqué de (numéro de version, dates de construction, etc.). En faisant tout ce travail dans un branche de libération, o développer une branche devient propre pour recevoir fonctionnalités de la prochaine grande Communiqué de [Version].

Le moment clé pour créer un nouveau branche de libération branchement à partir de développer c’est quand le développer est déjà (Presque) reflétant l’état souhaité de la nouvelle Communiqué de [Version]. Tous fonctionnalités les demandeurs de la Communiqué de à construire doit être incorporé [Fusion] le développer à ce stade. D’autre part que fonctionnalités visant à Versions à terme devrait s’attendre à une prochaine Communiqué de [Version].

C’est exactement au début d’une branche de libération que le prochain Communiqué de reçoit un numéro de version – pas avant. Jusqu’à ce point, o développer une branche reflète les changements apportés à la “prochaine version” [version suivante], mais il n’est pas clair si ce “version suivante” sera éventuellement 0.3 ou 1.0, jusqu’à ce que le branche de libération est démarré. Cette décision est prise au début de la branche de libération et est effectuée par les règles du projet sur la version [Je suggère de voir environ “Version sémantique“].

Création d’une branche de version

Lla libère des succursales sont créés à partir de la développer une branche. Par exemple, disons que la version 1.1.5 est la version de production actuelle et nous avons une grande Communiqué de Venir. L’état de développer est prêt pour le “version suivante” [prochaine version] et nous avons décidé que cela deviendrait la version 1.2 (Au lieu de 1.1.6 ou 2.0). Alors, nous nous ramons et donnons le branche de libération un nom reflétant le nouveau numéro de version:

$ git checkout -b libération-1.2 développer
# Switched to a new branch "release-1.2"
$ ./Bosse-Version.Sh 1.2
# Fichiers modifiés avec succès, version cogné à 1.2.
$ git commit -un -m "Bumped version number to 1.2"
# [release-1.2 74d9424] Numéro de version cogné à 1.2
# 1 Fichiers modifiés, 1 insertions(+), 1 Suppressions(-)

Après avoir créé un nouveau Direction générale de la et y accéder, nous sommes tombés sur le numéro de version. Ici, bump-version.sh est un script shell qui modifie certains fichiers de copie de travail pour refléter la nouvelle version. (Cela peut, Bien sûr, être un changement manuel – le fait est que certains fichiers changent.) Alors, est fait le Commettre du numéro de version modifié.

Cette nouvelle Direction générale de la peut exister là pendant un certain temps, jusqu’à ce que le Communiqué de être lancé en permanence. Au cours de cette période, corrections de bogues peuvent être appliquées dans ce Direction générale de la (au lieu de la développer une branche). L’ajout de nouveaux et grands fonctionnalités ici est strictement interdit. Ils doivent être fusionnés [Fusionné] dans développer et, Comme ça, attendre le prochain grand Communiqué de.

Finalisation d’une branche de libération

Lorsque le branche de libération est prêt à devenir une vraie version, certaines mesures doivent être prises. Première, o branche de libération est fusionné en maître (puisque chaque Commettre dans maître est une nouvelle version par définition, Rappelez-vous). Puis, Ce Commettre dans maître devrait être marqué pour faciliter une référence future à cette version historique. Finalement, les modifications apportées à la branche de libération doivent être fusionnés [Fusionné] à nouveau à développer, de sorte que le Versions les contrats à terme contiennent également ces corrections de bogues.

Les deux premières étapes de Git:

$ git maître de caisse
# Passé à la branche 'master'
$ git fusionner --dans-ff communiqué-1.2
# Fusion faite par récursif.
# (Résumé des changements)
$ tag git -un 1.2

Le Communiqué de est maintenant terminé et marqué pour référence future.

Remarque: vous pouvez également utiliser des drapeaux -s ou -u pour signer votre balise cryptographiquement.

Pour conserver les modifications apportées à la branche de libération, nous devons les remettre ensemble développer. Chez Git:

$ git checkout développer
# Passé à la branche 'développer'
$ git fusionner --dans-ff communiqué-1.2
# Fusion faite par récursif.
# (Résumé des changements)

Cette étape peut conduire à un conflit de fusion (probablement aller, une fois que nous changeons le numéro de version). Si c’est le cas, réparer et faire le Commettre.

Maintenant, que nous avons vraiment fini, o branche de libération peut être supprimé, puisque nous n’en aurons plus besoin:

$ branche git -d libération-1.2
# Libération de branche supprimée-1.2 (a été ff452fe).

Branches de correctif

– Il peut ramifier [Direction générale de la] De:
maître
– Doit fusionner [Fusion] encore une fois le:
développer et maître
– convention pour la nomination de la Direction générale de la:
correctif-*

Lla Branches de correctif sont très semblables à la succursales de libération, parce qu’ils sont également destinés à préparer une nouvelle version de production, bien que non planifiée. Elles découlent de la nécessité d’agir immédiatement après l’état non désiré d’une version de production [en cours d’utilisation]. Lorsqu’une erreur critique se produit dans une version de production, doit être résolu immédiatement, puis un branche de correctif peut être dérivé de l’étiquette qui marque la version de production existante dans le branche principale.

L’essentiel est que le travail des membres de l’équipe (dans développer une branche) peut continuer, alors que quelqu’un d’autre prépare une solution rapide de l’échec de production.

Création de la branche correctif

Lla branches de correctif sont créés à partir de la branche principale. Par exemple, en supposant que la version 1.2 est la version actuelle de la version de production en cours d’exécution et présente des problèmes en raison d’une grave erreur. Changements dans développer laisser le encore instable. Nous pouvons alors ramifier un branche de correctif et commencer à résoudre le problème:

$ git checkout -b correctif-1.2.1 maître
# Switched to a new branch "hotfix-1.2.1"
$ ./Bosse-Version.Sh 1.2.1
# Fichiers modifiés avec succès, version cogné à 1.2.1.
$ git commit -un -m "Bumped version number to 1.2.1"
# [correctif-1.2.1 41e61bb] Numéro de version cogné à 1.2.1
# 1 Fichiers modifiés, 1 insertions(+), 1 Suppressions(-)

N’oubliez pas de modifier le numéro de version après la branchement!

Puis, corriger l’erreur et Commettre de la correction dans un ou plusieurs Commettre Séparé.

$ git commit -m "Fixed severe production problem"
# [correctif-1.2.1 abbe5d6] Problème de production grave résolu
# 5 Fichiers modifiés, 32 insertions(+), 17 Suppressions(-)

Finalisation d’une branche de correctif

Une fois terminé, o Bugfix doit être fusionné de nouveau dans le maître, mais il doit aussi être incorporé dans développer, afin de s’assurer que le Bugfix est également inclus dans la version suivante. C’est assez similaire à la façon dont succursales de libération sont finalisés.

Première, mettre à jour le maître et marquer un Communiqué de [marquer l’été]:

$ git maître de caisse
# Passé à la branche 'master'
$ git fusionner --dans-correctif ff-1.2.1
# Fusion faite par récursif.
# (Résumé des changements)
$ tag git -un 1.2.1

Remarque: vous pouvez également utiliser des drapeaux -s ou -u pour signer votre balise cryptographiquement.

Puis, inclure le Bugfix dans développer aussi:

$ git checkout développer
# Passé à la branche 'développer'
$ git fusionner --dans-correctif ff-1.2.1
# Fusion faite par récursif.
# (Résumé des changements)

La seule exception à la règle ici est que, lorsqu’il y a un branche de libération en cours, les changements de Correctif doivent être fusionnés dans cette branche de libération, plutôt que développer. Fusionner le Bugfix dans branche de libération provoquera le Bugfix est fusionné dans le développer aussi, lorsque le branche de libération est terminé. (Si le travail dans le développer exige immédiatement cette Bugfix et ne peut pas attendre jusqu’à ce que le branche de libération est terminé, vous pouvez fusionner en toute sécurité le Bugfix à deveolp Également.)

Finalement, supprimer le Direction générale de la Temporaire:

$ branche git -d correctif-1.2.1
# Branche de correctif supprimée-1.2.1 (était abbe5d6).

Résumé

Bien qu’il n’y ait rien de vraiment extraordinaire dans ce modèle de branchement, le chiffre au début de la Poste peut être très utile dans nos projets. Il montre un modèle mental facile à comprendre et permet aux membres de l’équipe de développer une compréhension commune des processus de Branchement et Libérer.

Une version PDF de haute qualité de la figure est fournie sur le blog du post original: http://nvie.com/posts/a-successful-git-branching-model/ [ou dans le lien Télécharger ci-dessous]. Allez-y et placez-le sur le mur pour une référence rapide à tout moment.

Totales hits: 8861

Un commentaire sur “Un modèle de réussite des succursales à Git

  1. Deivson naissance a dit:

    Bonne après-midi, Je sais que Git a été initialement développé par le système Linux, mais lorsque l'on parle de portabilité, Je me demande si le Git fonctionne sur windows et POSIX MSIS??

Laisser une réponse

Votre adresse email ne sera pas publié. Les champs obligatoires sont marqués avec *