Je recommanderais d'utiliser tags (tag tutorial)
De la branche master depuis que vous avez terminé v1.0 ajouter une balise appelée v1.0.
git tag -a -m "Tagging release 1.0" v1.0
De cette façon, vous pouvez toujours revenir à une version spécifique à tout moment en appelant git checkout [tag_name]
Une autre pratique courante consiste à utiliser des branches pour travailler sur les caractéristiques jusqu'à ce qu'ils soient stables.
git checkout -b [feature-branch]
Cela crée une nouvelle branche nommée tout ce qui est en [feature-branch] et il vérifie. Assurez-vous de faire cela à partir de l'endroit où vous voulez commencer à travailler sur la fonctionnalité (généralement à partir de master).
Une fois stables, ils peuvent ensuite être fusionnés en toute sécurité en master. De master course:
git merge [feature-branch]
De cette façon, votre branche master reste toujours dans un état de fonctionnement et seulement les tâches terminées sont ajoutés une fois prêt. Cela vous permettra de garder une copie de travail de l'application à tout moment (idéalement de toute façon) pour les tests, etc.
Vous pouvez utiliser des branches pour chaque version de l'application, mais en utilisant les balises, vous ne pouvez pas fusionner dans une autre version de branche par accident.
D'accord. Archivez vos fichiers build et dsym 1.0 et ajoutez un tag. Si à l'avenir vous travaillez sur la version 2.0 et découvrez que vous devez libérer des modifications en tant que 1.1, vous pouvez toujours créer une balise à partir de cette balise.Il n'est pas nécessaire de créer une branche par version, mais vous pouvez fusionner votre branche de développement principale en une branche de publication unique chaque fois que vous créez une version ad hoc. Vous avez donc un historique clair du code disponible pour les tests. – Jonah
Ok, donc une fois que j'ajoute l'étiquette 1.0, comment puis-je commencer à travailler sur 1.1? Est-ce que je mets une autre étiquette? Confus à propos de ce concept. –
Pour construire le commentaire de Jonah, vous ne voulez qu'une branche pour une version si vous la maintenez séparément. Par exemple, si master travaille vers la version 3.0 mais que vous trouvez des bugs dans la version 2.0, vous pouvez créer une branche de maintenance à partir de la balise 2.0, éventuellement tagger la version 2.1, et fusionner cette branche dans votre branche master pour obtenir corrections de bugs dans la prochaine version 3 aussi. – Cascabel