Comment utiliser github, branches et versions automatiques pour la gestion des versions?
Je comprends maintenant la plupart des concepts de base de Git/Github, mais j'ai toujours du mal à comprendre la situation dans son ensemble.
Voici certaines choses que j'ai réussi à faire fonctionner jusqu'à présent:
- Push commits
- Travailler avec des succursales
- Intégrez Github à Travis CI, un système d'intégration continue
- Via Travis CI, construisez automatiquement sur chaque commit à master et mettez la version sous forme de Zip sur Github sous les versions.
Cependant, jusqu'à présent, je n'ai travaillé que sur des versions alpha/bêta de projets, donc je n'ai encore jamais vu de versions avec versions.
Je souhaite donc en savoir plus sur le contrôle de version, la maintenance de versions distinctes, le correctif des versions, etc.
Comment puis-je m'assurer que les choses suivantes se produisent:
- J'ai différentes versions de mon projet, par exemple les versions 1.1.0 et 2.0.0
- Avoir la possibilité de pousser les correctifs sur les versions, en quelque sorte de basculer la version vers 1.1.1 ou 2.0.1, etc.
- Créez un système d'intégration continue pour créer automatiquement cette version lors de la validation et, si cela réussit, puis publiez une version pour cette version spécifique.
Je doute entre les options suivantes:
- Dois-je utiliser des balises pour chaque version? Dans l'affirmative, comment un système d'intégration continue peut-il générer automatiquement des versions?
- Dois-je créer des branches pour chaque version? Si c'est le cas, cela ne créerait-il pas une tonne de branches (comme une branche 1.1 et 2.0, les correctifs vont bien sûr sur cette branche)
- Comment spécifier le numéro de version? Est-il acceptable d'avoir un fichier de configuration qui spécifie le numéro de version, ou existe-t-il des moyens plus intelligents? Dans ce cas, ce serait un projet Java, si cela importe.
Vous devriez regarder git-flow . C'est un excellent modèle de branchement (et populaire).
Résumé de Git Flow
Ramification
Les troncs principaux qui restent indéfiniment sont develop et master. master contient votre dernière version et develop contient votre dernière copie de développement "stable".
Les contributeurs créent feature branches (préfixées par feature/ Par convention) à partir de develop:
$ git checkout -b feature/my-feature develop
et hotfix branches (préfixées par hotfix/ par convention) hors de master:
# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master
# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>
Ces branches sont "jetables", ce qui signifie qu'elles ont une courte durée de vie avant d'être fusionnées avec les troncs principaux. Ils sont destinés à encapsuler de petites fonctionnalités.
Branches de finition
Lorsqu'un contributeur a terminé avec une branche feature, il la fusionne à nouveau dans develop:
$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature
Lorsqu'ils ont terminé avec une branche hotfix, ils la fusionnent à nouveau à la fois master et develop afin que le correctif continue:
$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number
C'est l'aspect d'intégration continue.
Communiqués
Lorsque vous êtes prêt à commencer à empaqueter une version, vous créez une branche release à partir de votre branche "stable" develop (identique à la création de branches feature). Vous cognez ensuite le numéro de version dans une balise (décrite ci-dessous).
L'utilisation de branches release distinctes vous permet de continuer à développer de nouvelles fonctionnalités sur develop pendant que vous corrigez des bogues et ajoutez des touches de finition à la branche release.
Lorsque vous êtes prêt à terminer la version, vous fusionnez la branche release en master et develop (tout comme un hotfix) afin que tous vos les changements se poursuivent.
Marquage
Lorsque vous créez une branche release ou une branche hotfix, vous bousculez le numéro de version de manière appropriée dans une balise. Avec Vanilla git, cela ressemble à ceci:
$ git tag -a <tag-name> -m <tag-description>
Vous devrez ensuite également pousser les balises (séparément) vers votre référentiel distant:
$ git Push --tags
Il est généralement préférable d'utiliser le contrôle de version sémantique dans lequel vos versions prennent la forme major.minor.hotfix. Les bosses majeures sont incompatibles en arrière, alors que les bosses mineures et correctives ne sont pas incompatibles en arrière (sauf si vous êtes en version bêta, 0.x.x).
Fusion
Comme vous l'avez vu ci-dessus, git-flow vous encourage à fusionner les branches avec la commande suivante:
$ git merge --no-ff <branch-name>
L'option --no-ff Vous permet de conserver tout l'historique de vos branches sans laisser un tas de branches traîner dans le commit actuel du dépôt (donc pas de soucis, vous n'aurez pas de branche pour chaque version).
Vous êtes également encouragé à tirer avec
$ git pull --rebase
Donc, vous n'ajoutez pas beaucoup de commits de fusion inutiles.
Vous pouvez configurer git pour faire ces deux choses par défaut dans votre .gitconfig. Je vous laisse le chercher cependant;)
Parcourir les versions
Lorsque quelqu'un recherche une version spécifique de votre base de code, il peut extraire la balise par son nom:
# checkout in detached HEAD to browse
$ git checkout <tag-name>
# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>
Ou, si quelqu'un navigue sur github, il y a aussi un onglet "tags" dans la liste déroulante "branches".
Utilisation de l'extension git-flow (recommandé)
Ma façon préférée d'utiliser ce modèle est avec le extension de flux git pour git.
( Edit: Louis a recommandé le AVH fork qui fonctionne mieux avec git describe Et pourrait être plus actif maintenant Merci Louis.)
L'extension automatise toutes les parties en désordre (comme l'utilisation de merge --no-ff Et la suppression de branches après la fusion) afin que vous puissiez continuer votre vie.
Par exemple, avec l'extension, vous pouvez créer une branche d'entité comme ceci:
$ git flow feature start my-feature-name
et finir comme ça
$ git flow feature finish my-feature-name
Les commandes pour les correctifs et les versions sont similaires, bien qu'elles utilisent le numéro de version à la place d'un nom de branche, comme ceci:
# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14
# Create the next release
$ git flow release start 2.5.0
Git flow crée ensuite la balise de version pour vous et vous rappelle gentiment de bump la version dans n'importe quelle configuration ou fichier manifeste (ce que vous pourriez faire avec un gestionnaire de tâches comme grunt).
J'espère que cela vous aidera :) Je ne sais pas exactement comment vous intégreriez tout cela avec votre configuration Travis CI, mais je suppose que les githooks vous y mèneront.
Dois-je utiliser une balise pour chaque version?
Non, vous n'avez pas besoin d'utiliser des balises. Si vous voulez baliser chaque version, c'est bien, ou si vous voulez baliser chaque fois que votre système CI se construit, vous pouvez le faire aussi. Les balises donnent essentiellement un nom convivial à la validation, de sorte que vous pouvez facilement la récupérer et la visualiser plus tard.
Dois-je créer des branches pour chaque version?
Sûr! Le branchement est bon marché/gratuit à Git, donc j'en profite chaque fois que j'en ai. Vous pouvez également fusionner et supprimer des branches assez rapidement également. Si vous sentez que vous avez de nombreuses branches, vous pouvez toujours les réduire plus tard avec une fusion sélective. Il existe également une multitude de schémas de branchement Git si vous souhaitez utiliser un schéma éprouvé.
Comment pourrais-je spécifier le numéro de version?
Les balises sont généralement la façon dont vous spécifiez le numéro de version, en ce qui concerne git. Si vous parlez de la version d'un projet, ou de la meilleure façon de le faire, vous devrez creuser, car c'est une question assez basée sur l'opinion. Certains projets restent en version bêta pour toujours, d'autres incrémentent les versions de nombres entiers comme s'ils se démodaient (vous regarde chrome)
Dois-je utiliser des balises pour chaque version?
Si par "version" vous entendez un ensemble de fichiers qui composent une version ou une version candidate, je recommande fortement de baliser chaque version. Si vous devez vous référer à la version 1.2.7 plus tard, voulez-vous rechercher le hachage d'un commit ou simplement utiliser le numéro de version?
De plus, si vous utilisez git describe pour enregistrer les informations de construction quelque part (comme je le fais), puis l'utilisation de balises lui permet de fournir une sortie beaucoup plus agréable.
Dans l'affirmative, comment un système d'intégration continue peut-il générer automatiquement des versions?
Un système d'intégration continue pourrait créer des versions quelle que soit la façon dont vous utilisez les balises. Vous pouvez lui dire de construire une version sur la base du hachage d'un commit. Les tags vous facilitent la vie.
Dois-je créer des branches pour chaque version? Si c'est le cas, cela ne créerait-il pas une tonne de branches (comme une branche 1.1 et 2.0, les correctifs vont bien sûr sur cette branche)
Je ne vois pas la ramification comme une chose "par version". J'ai quelques projets où mes versions sont toutes validées sur la branche master. Je n'ai besoin de rien de plus compliqué que cela pour l'instant car aucun des deux projets n'est au stade stable et il n'est pas nécessaire de supporter les anciennes versions à long terme. Mais disons que je publie 1.0, 1.1, 1.2, puis je publie 2.0 et je dois toujours prendre en charge la série 1.0 avec des correctifs de sécurité, etc. Ensuite, j'aurais certainement une branche pour mettre les versions de maintenance pour la série 1.x .
Comment spécifier le numéro de version? Est-il acceptable d'avoir un fichier de configuration qui spécifie le numéro de version, ou existe-t-il des moyens plus intelligents? Dans ce cas, ce serait un projet Java, si cela importe.
Avoir une source unique pour votre numéro de version, comme un fichier de configuration, est le meilleur moyen car il empêche les erreurs de gros doigt qui pourraient autrement se produire si vous devez mettre à jour les numéros à plusieurs endroits. Je parle de ... hmm ... une expérience embarrassante. Vous publiez 1.3 uniquement pour constater que le logiciel signale toujours qu'il s'agit de la version 1.2. Oops!
Dans une autre réponse, mxdubois vous a recommandé gitflow. Si vous décidez d'utiliser gitflow, je vous recommande d'utiliser édition AVH . La version originale n'est plus activement maintenue. Une différence notable est que l'édition AVH effectue des fusions de versions qui permettent git describe pour travailler intelligemment. La version d'origine effectue la fusion d'une manière qui déclenche git describe .
En parcourant votre liste, je vois la version comme votre objectif, alors ...
Une façon de maintenir les versions est de créer des branches et de fusionner (ou rebaser).
Vous avez donc:
master
puis vous créez une branche
v1
puis vous ajoutez d'autres modifications à
master(diff1)
puis vous créez une branche
v3
puis vous ajoutez d'autres modifications à
master(diff2)
Maintenant:
Pour mettre à jour la version 2, vous devez maintenant
git checkout v2
git merge master # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.
Pour mettre à jour la version 3
git checkout v3
git merge master
Ce qui précède est pour les mises à jour en gros.
Il est probablement plus probable que vous souhaitiez sélectionner des modifications spécifiques pour qu'il y ait
git cherry-pick
Plus d'informations sur la cueillette des cerises sur http://git-scm.com/docs/git-cherry-pick