J’aimerais avoir quelques précisions (voire un mini-tuto) sur l’utilisation d’un gestionnaire de version dans le cadre des FI. Pour l’instant, j’utilise Mercurial sur Bitbucket, mais ce sont plutôt des concepts généraux que j’aimerais mieux connaître. Je ne cherche pas sur l’internet, parce que je ne veux pas un guide complet sur des fonctionnalités que je n’utiliserai jamais, juste quelques indications.
Donc, j’aimerais surtout savoir ce que sont exactement les branches et les tags, leurs différences, et si c’est utile de les utiliser pour des FI et des extensions I7. Pour l’instant, je ne fais que commiter et pousser, il se peut que ça suffit et que je n’ai pas besoin de m’embêter avec toutes ces subtilités, mais Stormi avait mentionné l’utilité des tags dans un vieux message.
Si quelqu’un a des astuces ou remarques sur l’utilisation d’un gestionnaire de version, je suis preneur, et on pourrait même en faire un article le (très prochain) nouveau site !
je ne pourrais pas trop t’aider, je n’utilise jamais les tags, les branches et compagnies, je trouve ça trop compliqué En fait j’utilise mercurial comme un système de backup / historique avec divers points de restauration…
Moi c’est pareil, mais ça peut peut-être servir, par exemple pour avoir plusieurs versions de l’extension française : un tag pour 6L02, un tag pour 6L38, un tag pour 6M62. Comme ça, si je fais une correction pour 6M, mais qui fonctionne aussi pour 6L, ça permet d’avoir aux utilisateurs d’anciennes versions d’Inform d’avoir une extension à jour.
Ou alors, pour mes FI, je pourrais tagger les différentes versions sorties officiellement (genre tel commit correspond à la release 1, tel commit à la release 2, etc.)
Mais je ne sais pas s’il faut utiliser des branches, des tags ou autre pour ça, et c’est possiblement se compliquer la vie pour rien (pourquoi quelqu’un qui utilise 6L02 ne voudrait pas passer sur 6L38 ?). Alors j’aimerais bien l’avis des autres.
Pour l’instant, c’est une personne en faveur de « se compliquer la vie pour rien ».
Dans mon boulot, on utilise les branches et les tags de cette façon :
Les tags : ils indiquent à quelle version applicative globale appartient chaque fichier. C’est ce que tu appelles les « différentes versions sorties officiellement ».
Les branches : elles permettent de gérer en parallèle plusieurs versions applicatives sur lesquelles l’équipe travaille en même temps. Ce n’est peut-être pas très clair, alors je vais illustrer avec un exemple. Supposons qu’on doive inclure une nouvelle fonctionnalité dans une version 3 d’un jeu. Mais avant la sortie de cette version 3 (qui prend du temps à être développée, ou dont la nouvelle fonctionnalité n’est pas requise avant une date précise), il faut corriger des bugs sur la version 2 et proposer rapidement une version 2.1. On crée donc une branche pour la version 2.1, le tronc étant réservé à la version 3. On n’oublie pas de reporter les corrections et autres petites modifications de la branche vers le tronc.
J’espère que ces infos pourront t’aider dans tes choix.
+1 à ce que dit Eva ; je crois que dans ton cas ça serait « une branche 6G60, une branche 6L38, etc. » et un tag pour chaque version « stable » (et oui, par exemple, un tag pour la v1 de ton jeu, un autre pour la v2, etc). Alternativement, les branches ça sert à faire un bac à sable pour implanter une grosse feature (pas la peine de « polluer » ton dépôt principal avec plein de commits pour une grosse fonctionnalité qui marche pas encore, vaut mieux faire une branche (ou un fork) et travailler dessus, puis faire un merge).
Ça confirme plus ou moins ce que j’avais trouvé dans mes recherches. Merci !
Deux autres questions :
On ne risque pas de se retrouver avec une montagne de tags (si mon jeu à 36 versions, il y aura 36 tags différents) ?
Et est-ce que ça vaut la peine pour de simples FI, où il n’y a en général qu’un seul fichier de code ? Aussi, je ne vois pas trop l’intérêt de faire des tags pour chaque release de l’extension française, puisqu’en gros chaque commit est une nouvelle sortie, il n’y a pas de versions « figées » (j’espère que je me fais comprendre).
Je vais peut-être essayer de mettre des tags au moins sur mes FI, ça me permettrait de savoir à quel commit correspond chaque version.
Si. C’est typiquement le cas pour une appli avec une longue durée de vie. Mais je ne vois pas en quoi c’est gênant. Je ne connais pas ton gestionnaire de version, mais avec tortoiseSVN, celui dont j’ai l’habitude, peu importe le nombre de tags créés.
Effectivement, c’est un peu sortir l’artillerie lourde pour pas grand-chose. Un gestionnaire de version est avant tout fait pour aider le développement d’un projet avec plusieurs fichiers et sur lesquels plusieurs personnes travaillent ensemble. Pour une FI en un fichier, sur laquelle tu travailles seul, si j’ai bien compris, tu n’as pas besoin de toutes les fonctionnalités dispo.
Oui, c’est ce que je pensais aussi. J’utilise Bitbucket surtout pour avoir un historique des modifications et une sauvegarde de mes projets, je n’ai pas vraiment besoin d’utiliser tout ce que m’offre un gestionnaire de version. Mais au moins je sais mieux à quoi ça sert, et il se peut que j’utilise ce j’ai appris ici pour certains de mes projets.
Un autre truc, qui est un peu HS par rapport à ta question spécifique mais pertinent par rapport aux gestionnaires de version, c’est les systèmes de suivi d’anomalies. J’adore ces trucs-là, et j’en n’avais pas utilisé avant de me mettre sur bitbucket (même si on peut très bien avoir un système de suivi d’anomalie sans gestionnaire de versions nécrssairement couplé - Inform esr sur Mantis alors que le code est sur Github). Bref, j’adore remplir ces trucs-là (en lisant des transcripts par exemple), puis les vider petit à petit (« pff pas la motiv… Allez, juste un bug facile » et bim, le doigt dans l’engrenage). Celui de bitbucket est super : quand ton message de commit contient « fix bug 15 », il ferme le bug 15 avec en commentaire un lien vers le commit - super pratique
J’utilise ça aussi comme liste de TODO pendant le développement, pour faire la liste des trucs qu’il reste à faire. J’avais une vingtaine de ‹ bugs › résolus à la fin du développement de Tipelau (et là j’en ai 133 à faire :p)
Un des trucs cools sur Github, aussi, c’est qu’il compte le nombre de jours consécutifs où t’as contribué, et tu peux essayer de garder ça en vie le plus longtemps possible (et des fois tu te dis « pas envie, mais je veux garder ma ‹ streak ›… Allez, un petit coup au moins »). Andrew Schultz est super motivé par ce truc apparemment, il en est à 160 jours de suite (vous imaginez? 6 mois avec un peu d’IF chaque jour? La vitesse à laquelle nos projets avanceraient? )
Non, c’est pas forcément hors-sujet, c’est même un bon point ! J’oublie qu’on peut aussi utiliser ça comme liste de tâche et pas comme quelque chose réservé strictement aux bugs.
En fait j’utilise mercurial comme un système de backup / historique avec divers points de restauration…
)