Comment utiliser github, branches et versions automatiques pour la gestion des versions? [fermé]

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 cette version automatiquement 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 correct 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 importait.

Vous devriez regarder git-flow . C'est un excellent modèle de branchement (et populaire).

Résumé de Git Flow

Ramification

Les principaux troncs qui restent pour toujours sont developet master. mastercontient votre dernière version et developcontient votre dernière copie de développement "stable".

Les contributeurs créent des featuresuccursales (préfixées feature/par convention) à partir de develop :

$ git checkout -b feature/my-feature develop

et hotfixbranches (préfixées hotfix/par convention) à partir 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 featurebranche, 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 hotfixbranche, ils la fusionnent à nouveau dans les deux masteret developdonc le correctif se poursuit:

$ 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 releasebranche à partir de votre branche "stable" develop(identique à la création de featurebranches). Vous cognez ensuite le numéro de version dans une balise (décrite ci-dessous).

L'utilisation de releasebranches distinctes vous permet de continuer à développer de nouvelles fonctionnalités pendant developque vous corrigez des bogues et ajoutez des touches finales à la releasebranche.

Lorsque vous êtes prêt à terminer la version, vous fusionnez la releasebranche dans les deux masteret develop(tout comme a hotfix) afin que toutes vos modifications soient reportées.

Marquage

Lorsque vous créez une releasebranche ou une hotfixbranche, vous transférez 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 versionnage 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' --no-ffoption vous permet de conserver l'intégralité de votre historique de branche sans laisser un tas de branches traîner dans le commit actuel du référentiel (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 l' extension git flow pour git.

( Edit: Louis a recommandé la fourche AVH qui fonctionne mieux avec git describeet pourrait être plus active maintenant. Merci Louis.)

L'extension automatise toutes les parties en désordre (comme l'utilisation merge --no-ffet 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 absolument pas besoin d'utiliser de 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 simplement 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 l'occasion. Vous pouvez également fusionner et supprimer des branches assez rapidement également. Si vous pensez 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 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 describepour enregistrer des informations de construction quelque part (comme je le fais), l'utilisation de balises 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 masterbranche. 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 prendre en charge 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 correct 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 importait.

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 l' é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 describede travailler intelligemment. La version originale effectue la fusion d'une manière qui se déclenchegit 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)

À présent:

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