portage sur ipad (application universel)
Bonjour,
On m'a fourni le code source de l'application iphone qui est en cours de dev pour que je fasse la partie ipad pour que l'application soit Universelle (tout dans le meme package)
N'ayant jamais été confronté à ce cas de figurer, je me demande comment il faut procéder dans une tel situation ?
Il faut définir des viewController spécifique à la version ipad et faire de la programmation conditionel suivant que c'est l'ipad ou iphone qui est détecté ?
Aussi comment géré au mieux le fait l'application est en cours de développement sur les 2 devices pour que mes modifs ne cassent pas le boulot de la version iphone et vis versa
merci
Lunack
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Salut,
Généralement Il te faut un seul controller par vue ( écran), par exemple si tu a un un écran authentification t'aura AuthentifactionVC et deux xibs AuthentificationVC~iphone.xib ( pour le vue écran iPhone) et AuthentificationVC~ipad.xib ( pour la vue iPad). a toi de faire le choix aussi de créer une seule vue si tu juge que les deux écran se ressemble.
Pour ta deuxième question, il faut tester sur iPhone et iPad, y a pas d'autres solutions miracles, mais le mieux c'est de tester régulièrement. Sinon t'a les Test Unitaires,....
PS : Si les deux applications iPhone et iPad sont complètement différentes, dans ce cas moi je préfère créer des controller différent pour avoir un code propre et facile a maintenir.
L'application ipad est identique
Utilise juste ce dont tu as besoin, un VC différent s'il te faut un VC différent, le même s'il n'y a pas besoin d'un différent...
Pour chaque écran
- Si le comportement et les éléments de l'interface sont les mêmes
- Si c'est carrément le même look, la même disposition (c'est juste une zone plus grande sur iPad que sur iPhone mais sinon c'est la même chose) autant n'avoir qu'un seul XIB et qu'un seul ViewController. Par exemple si c'est une UITableView plein écran ou une UICollectionView plein écran dans les 2 cas, bah ça sera la même chose, pas besoin de ViewControllers différents. Quitte à utiliser les AutoResizingMask, voire AutoLayout si tu codes pour iOS6+, pour s'assurer que tes vues gardent bien leurs positions relatives quand l'écran est plus grand (mais bon ça tu dois déjà avoir fait mumuse avec pour gérer l'écran 3.5" vs écran 4" de l'iPhone 5 à priori), ou même un peu de code pour ajuster les frames si les ARM ou AutoLayout ne te suffisent pas.
- Si tu as les mêmes éléments sur l'écran iPhone et iPad, mais positionnés un peu plus différemment que juste un étirement de l'écran, genre tes éléments de ton UI sont les mêmes mais ne sont pas du tout organisés pareil (disons sur iPhone une ImageView en haut et une TableView en dessous, sur iPad l'ImageView à gauche et la TableView à droite, par exemple), dans ce cas, tu peux toujours utiliser le même UIViewController et son .h et .m, mais avoir deux XIB différents, un pour iPad et un pour iPhone. Dans ce cas tu as les conventions de nommage indiquées par @samir2303 pour nommer tes XIB et qu'il charge automatiquement le bon selon le device.
- Si vraiment tu as des comportements totalement différents sur iPhone et sur iPad, genre sur iPhone tu as une TableView pour juste lister des éléments, alors que sur iPad tu as une CollectionView avec un effet Carrousel ou autre, des cellules qui n'ont rien à voir... ou bien sur iPhone tu as des onglets TabBarController parce qu'il n'y a pas la place de tout mettre sur l'écran, mais sur iPad tu veux tout dans le même écran car il y a la place, etc... Là tu code n'aura rien à voir sur iPhone et sur iPad, du coup ça vaut peut-être le coup de faire un UIViewController pour chaque cas, et par code de charger le bon quand tu le push avec des tests conditionnels en utilisant UI_USER_INTERFACE_IDIOM()
Dans tous les cas, tu as forcément un Programming Guide sur le sujet qui te donne toutes les billes pour faire ça et qui va répondre à toutes tes questions (je l'ai pas cherché, mais c'est toujours le cas)[EDIT]Bingo.
merci Aligator encore pour ta réponse exhaustive
Travail en collaboration avec un bon gestionnaire de version, git est très bien.
Commits fréquents.
Merges sur la branche master le plus fréquemment possible, dès qu'on a une petite fonctionnalité supplémentaire stable.
Merge ou Rebase fréquents avec la branche master en cours de Dev sur sa propre branche.
Et pour aller plus loin et plus vite :
Tests unitaires automatisés
Intégration continue
J'utilise Git-Flow et SoureTree : c'est la belle vie
http://nvie.com/posts/a-successful-git-branching-model/
Je viens précisément de finir 5 jours à travailler exactement sur ça d'ailleurs donc tu peux pas mieux tomber en terme de REX.
- Pendant que mes collègues travaillaient sur le master, moi je me suis créé une branche 'ipad', j'ai travaillé sur le portage de l'appli sur iPad, et je les embêtais pas.
- A chaque fois que j'avais fini de porter un écran (vérifier le XIB, ajuster les AutoresizingMasks, vérifier que le code n'avait pas de Magic Numbers et sinon remplacer les valeurs en dur dégueulasses par des valeurs dynamiques ou des constantes...)
- J'ai fait de temps en temps des merges de 'master' dans ma branche 'ipad' pour récupérer leurs modifications (ce qui est optionnel mais ça permet de récupérer au fur et à mesure leur boulot et leurs BugFixes, plutôt que d'attendre d'avoir fini et de devoir faire un gros merge). Je préfère faire ça dans ce sens pour pas polluer la branche master avec mes travaux tant qu'ils ne sont pas finis et les laisser tranquilles (un peu à la git-flow, à chaque feature sa branche), mais quand même éviter que les 2 branches divergent trop et que le merge soit trop violent à la fin, mais bon chacun fait comme il veut selon le workflow de son équipe.
- A la fin quand j'ai eu fini tous les écrans, j'ai mergé ma branche 'ipad' sur le 'master' et basta.
On a sur tous nos projets des Tests Unitaires (OCUnit + OHHTTPStubs) et de l'intégration Continue (Jenkins) donc ça garantis que les builds ne cassent pas, et que mes modifs sur ma branche ou mes merges n'empêche pas les autres de compiler.
Cependant pour un portage sur iPad où le travail de portage se fait surtout sur l'IHM (bon positionnement des vues, etc) et où normalement tu as peu d'impact sur le fonctionnel, les TU fonctionnels ne garantissent pas trop que tes designs sont toujours OK. Ca y'a pas de mystère, soit tu as un framework qui sait faire des tests de positionnement d'interface (ça existe, mais bon c'est un peu plus casse-bonbon à mettre en place que des TU faits en 2mn), soit tu fais confiance à ton équipe de validation pour vérifier la non-régression UI (j'ai envoyé un OTA de l'appli en question en recette ce matin justement on verra ce qu'ils vont remonter dans Mantis demain ^^)
ça fait peur ça
. Je pense que c'est pas une bonne idée de travailler sur le Master meme si pour fixer des bugs ... risque d'un gros merge,...
En pratique on est en VABF sur le projet principal, et ma branche de portage iPad se faisait en parallèle de cette VABF sur la version iPhone. Ce qui veut dire que le client n'a pas encore la version toute finale car on a encore des bugs à corriger, mais on n'a plus de nouvelle feature et on est quand même sur la Release Candidate 1.0 qu'il a pu tester pour nous y remonter des bugs.
Du coup, comme on ne suit pas encore git-flow à la lettre (c'est prévu
- Mes collègues faisait de la correction d'ano Mantis sur le "master" (en général de petites anos de VABF donc une ano = un commit " avec le message de commit "Fix #xxx"), et puisqu'on est en VABF c'était que des bugfix et donc pas de grosse feature
- Du coup je pouvais récupérer ces petits bugfixs du master régulièrement sans trop de risques
- On aurait déjà eu une release branche "release-1.0", préparée, mergée dans le master et taguée "1.0", version pseudo-finale fournie au client en début de VABF (je l'aurai plutôt appellée "iPhone RC 1.0" d'ailleurs à la limite)
- On rentre en VABF, le client nous fait ses retours de bug. A ce stade on va corriger des bugs à gauche à droite, en général pas bien gros corrigés en un petit commit, quoique certains peuvent justifier une branche dédiée s'ils sont plus complexes. Mais en tout cas on ne va pas rajouter de feature sur la version iPhone
Déjà du coup pour ça tu vois ça comment ? J'appelle pas trop ça du hotfix (car certaines anos remontées ne sont pas forcément critiques pour autant), pour moi ça sera une "release-1.1" à la fin (ou "iPhone 1.0 Final" quoi, pour aller après la Release Candidate) donc comme pour une nouvelle itération.
1) Du coup ce qui me semble le plus logique c'est de revenir dans develop et de faire ces corrections de bug dans "develop" (commit directement sur develop pour les petits bugs à la limite, ou dans des branches "bugfix/xxx" pour les bugs plus conséquents). La seule différence avec une itération normale c'est qu'au lieu d'avoir des branches "feature/*", vu qu'en VABF on n'a pas de nouvelle feature, j'aurai des branches "bugfix/*" (tirée de develop et mergés dans develop comme serait une "feature/*"). Quand tous les bugs Mantis remontés par le client seront corrigés, on crée une release-1.1, on la file à notre équipe de validation qui nous remonte les petits détails éventuels et régressions possibles, on corrige direct ces derniers points sur release-1.1, et à la fin on merge sur develop + master, on tag 1.1 et on livre au client.
2) Une autre possibilité serait de considérer que comme c'est de la VABF et donc que du Bugfix, on ne travaille pas sur develop mais sur une RC. Et donc dès le début de la VABF on crée une branche release-1.1 (ce fork qui partirait de develop serait du coup situé immédiatement après le merge de release-1.0 dans develop qu'on a fait après la livraison client et le tag 1.0), et on commit dessus comme on commiterai des bugfix sur une Release pour fignoler les derniers détails. Ce qui va bien avec la définition de git-flow d'une "release branch" qui est une branche où on ne fait que les derniers bugfix avant livraison et jamais de nouvelle grosse feature.
Sauf que du coup si on fait ça, quand on livre une version à notre équipe de recette interne avant de livrer au client, on fait quoi ? On peut pas rester sur cette branche, on n'aurait pas de branche dédiée pour les corrections uniquement remontées par l'équipe de tests interne comme on fait d'habitude...
3) La 3e possibilité c'est de considérer que la VABF c'est des corrections d'anos directement sur la version finale et donc d'utiliser des branches "hotfix/*" pour chaque bug remonté par le client en VABF, mais ça me parait un peu violent comme raccourci. Et de toute façon on ne relivre pas une version à chaque correction de bug, on attend de les avoir tous corrigés pour relivrer une version, donc ça ça ne m'irai pas comme modèle.
Au final je pense que la première solution est plus adaptée (corriger les bugs remontés par le client en VABF directement sur develop ou sur des branches "bugfix/*" équivalentes aux branches "feature/*"), mais toi qui a l'air de revendiquer et réellement pratiquer git-flow tu en penses quoi ?
Et du coup, pour en revenir au sujet d'origine, pendant tout ce process de VABF fait par mes collègues, on a eu un complément au contrat (demande d'évolution) pour porter l'appli sur iPad finalement (le client qui sait pas ce qu'il veut et se réveille tardivement... mais bon passons) donc le process normal pour moi c'est de créer une branche "feature/ipad" (fork de develop), de bosser dedans pendant que les autres font leur branches "bugfix/xxx" et les mergent régulièrement dans "develop", et moi quand j'ai fini mon portage iPad je merge "feature/ipad" dans "develop".
Et pour en revenir à la remarque d'origine sur les merges réguliers, pendant mon développement de mon portage iPad, pour pas attendre la fin de ma grosse feature avant d'intégrer tous leurs petits bugfix, régulièrement je merge "develop" (qui aura, depuis que j'ai forké "feature/ipad" de cette branche, évolué pour inclure divers correctifs via le merge de plusieurs branches "bugfix/*") dans ma branche "feature/ipad", comme ça je récupère au fur et à mesure les correctifs de "bugfix/xxx" qui y ont été reportés plutôt que d'attendre mon merge final de feature/ipad dans develop pour tout merger et régler tous les conflits d'un coup.
Qu'en penses-tu ? C'est bien ça la bonne pratique que tu verrais ?
Personnellement :
- lorsqu'un bug sur la branche master ne nécessite qu'un seul commit, je m'autorise le raccourci de le faire directement sur master
- lorsque je récupère la branche principale sur mon développement, je préfère un rebase à un merge, c'est plus esthétique qu'autre chose (je ne l'impose pas aux autres développeurs), ça évite les plats de spaghetti lorsque les branches sont longues.
Quand on fait des branches, c'est bien de savoir pourquoi on les fait.
Avec la facilité de faire des branches sur git, j'ai l'impression que certains développeurs suivent des modèles (git-flow, github-flow, etc) sans savoir pourquoi.
Pour ceux qui travaillent avec git-flow, mais qui ne savent pas pourquoi, je vous conseille de jeter un oeil sur le concept de Tofu scale de Perforce.
http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf
Le meilleur modèle c'est celui qui permet d'éviter de créer des branches car les branches, il faut les gérer, les merger, et ça prends du temps. Je parle bien sûr des branches communes (sur le serveur).
On peut être une équipe de pro et travailler sans branches, il n'y a pas de "honte" à ça. Tout dépend du contexte et des besoins.
(Attention, j'ai dit sans branches, pas sans gestion de conf.)
Idéalement, s'il n'y avait pas de bugs, ni de développements en parallèle, on travaillerait sur une seule branche master et les versions seraient taggées les unes après les autres.
1/bugs et (hot)fixes
Malheureusement, quand une version est sortie, on trouve des bugs et on doit les corriger ET les releaser pendant que la prochaine version est en cours de développement.
On va donc créer des branches de fixes qui seront hyper stables puisque ce sont les versions releasées avec juste quelques corrections.
Il est interdit de merger vers ces branches.
On doit, en revanche, merger depuis ces branches vers la branche master pour réintégrer les fixes dans la version 'en cours'.
Ces branches de fixes sur des releases anciennes ne sont pas nécessaires si on est dans un contexte où on s'interdit de sortir des patchs entre deux releases. Dans ce cas, autant corriger sur la branche master (j'ai l'impression qu'Apple travaille comme ça sur les produits mineurs où on se traine des bugs jusqu'à la prochaine release).
Pour les gens qui ne travaillent que sur une seule version en cours, il n'est pas nécessaire d'aller plus loin, on aurait donc :
la version en cours (master) et une branche pour chaque release qui a dû subir des fixes après avoir été livrée.
2/Les branches features
Parfois, on développe plusieurs features en même temps et, on souhaite pouvoir garder la possibilité de ne pas sortir l'une de ces features ou de la sortir pour une release qui ne sera pas la prochaine (car on n'est pas sûr d'etre à l'heure ou alors on sait déjà que la feature vise une version N+2).
Dans ce cas, on doit créer des branches de features.
Ces branches de features ne doivent etre mergée dans la branche master que lorsque la feature est terminée.
En revanche, la branche master doit être mergée dans ces branches features de manière régulière pour y réintégrer les hotfixes et les développement en cours (ou les autres branches features achevées qui ont été réintégrées dans la branche master).
Ali, dans ton cas, je corrigerais les bugs trouvés sur la version en cours de vérification directement sur la branche master puisqu'il s'agit de la prochaine release, à moins que ton client ne soit vraiment indécis et dans ce cas , il faut créer une branche feature pour ces fixes.
Je ferais le dev de la version iPad sur une branche feature en réintégrant les fixes qui viennent de master régulièrement comme tu l'as décrit.
Une autre manière de voir : plus on souhaite se garder des options pour l'ordre et le contenu des releases futures, plus on aura de branches.
Si on admet que les branches ont un coût, on a un donc un moyen de mesurer le coût de l'indécision et de l'insécurité dû à un client qui changent d'avis. Un metrics quoi, mais un metrics qui ne fait pas forcément plaisir au client.
Encore une autre manière de voir : vous faites des branches pour tout, ce qui donne une grande flexibilité à votre client pour décider dans quel ordre vous allez sortir les fixes et les releases, c'est la technique 'subway', il met ce qu'il veut, quand il veut, dans son sandwich et vous lui offrez un confort (qui a un coût).
Bonjour,
1.
- J'ai deux branches principales : Develop et Master.
- Pour une Feature je crée une branche develop/myFeature ( origin develop). Comme le cas de @Aligator pour la version ipad.
- Faire des pull régulier de Develop dans myFeature branche pour être à jours avec le travail des collègues. comme expliqué par @Aligator.
- A la fin de la version iPad je merge tout dans Develop avec un fast-forward si possible pour créer un commit point.
- Je supprime ma branche myFeature.
2.
- Pour chaque Release, je crée une branche develop/myRelease1.1 par exemple. La durée de vie de cette branche est jusqu'a mettre en prod cette version, je veux dire par la jusqu'a la validation du client par exemple, je merge cette branche dans le master er develop et je tag le master. C'est la, a mon avis, que tu peux faire les corrections de tes Bugs @Aligator quelque soit l'origine des retours ( bêta testeurs interne ou bien client).
3. Les hotfix : Ce qui j'ai compris de ça, c'est comme une branche release, aussi c'est des bugs graves d'une version de production en cours. je crée une branche d'origine master et je fix le bug, merge avec develop et master avec un tag de master de la nouvelle version de production.
Si une version release est en cours il ne faut pas merger dans develop la branche hotfix mais plutôt dans cette branche release.
Je ne suis pas un expert git ni développement d'ailleurs, j'ai juste exposé ma façon de travailler et ce que j'ai compris de git. Donc je n'ai pas vraiment de conseil a vous donner , j'espère que ça viendra un jours
Après ma question c'était plutôt pour la phase de VABF qui ne consiste à faire que du bugfix et pas de new features, mais qui est quand même longue et suit un cycle classique de dev (=plein de bugfixes) + recette interne + livraison client. Donc faire le même principe que pour une nouvelle itération/version (develop, release-*, puis merge dans master+develop + tag) me paraissait pas mal pour permettre de garder le principe de passer sur une branche release-* dédiée quand on passe à la validation interne de notre version qui corrige tous ces bugs, mais je suis preneur d'avis sur la question.
1. je suis d'accord.
2. Une branche de release doit une branche assez stable, donc s'il y a beaucoup de bugs/évolutions mineurs, autant créer une branche de feature car tu vas déstabiliser la version et ça va prendre un certain temps, dans l'intervale il est possible qu'un bug vraiment bloquant gêne la validation et donc là tu vas avoir besoin d'une branche release pour sortir un hotfix.
3. Cf ci-dessus, une branche release, c'est branche de maintenance d'une version donnée sur laquelle tu vas faire des petits patchs pour débloquer les gens qui utilisent cette version. Le but n'est pas de corriger 50 bugs d'un coup sur une branche release.
Mais je regrette un peu car maintenant que tous les bugfix ont été faits et poussés sur le master et qu'on envoie la version en recette interne, je serai partant de faire une branche comme je fais d'habitude (pour séparer la partie "on est en phase de recette et on ne corrige plus que ces petits détails que nous remonte l'équipe de Test & Valid sur l'existant" d'éventuels commits "on continue à travailler", pour éviter que ne soient rajoutées des features ou des bugfix qui ne sont pas inclus dans la version livrée à l'équipe de test et qui risqueraient sinon d'être intégrés à la version finale sans avoir jamais été testés par l'équipe d'intégration).
Tu vas me dire je peux toujours faire une branche "release-1.1" à partir de ce master pour isoler cette phase de recette, mais du coup ça sort un peu du principe suggéré par git-flow que de créer des branches autres que hotfix depuis le master. Après, est-ce que c'est grave de sortir des rails pour ça si ça colle à mes besoins...
Je suis d'accord avec ton auto-réponse : tu peux toujours faire une branche après coup.
Le seul intérêt que je vois de faire une branche feature pour ta version 1.1, ce serait dans le cas où tu aurais une feature qui devrait être livrée avant la version 1.1. Par exemple, un module indépendant que la validation n'a pas encore testé et que vous n'aviez pas fini au démarrage de la validation et que tu dois donc livrer avant de livrer les corrections.
Mais quand on commence à bosser en parallèle de la validation sur la version en cours de validation, ça sent mauvais.
Bah tous les avis sont bons à prendre c'est pour ça que je demande
Enfin pas tout à fait, mais c'est vrai que le planning en question est du grand n'importe quoi pour le coup (je me suis pas gêné pour le remonter au CDP mais bon), car y'a en même temps la VABF et la feature iPad, et on a livré hier à l'équipe de validation interne une version qui contient les 2 (merge de feature/ipad dans le master qui contient les bugfix de la VABF) qui a beaucoup à tester sur cette version du coup...
Enfin bon, merci pour ces retours, c'est toujours bon à prendre des expériences sur des vrais projets concernant ces choses là .
Tofu Scale.
Non FKDEV.
Les principes d'utilisation de SVN et celui de Git ne sont pas les mêmes.
Les bonnes pratiques avec des outils SVN-like (comme Perforce) sont de limiter l'utilisation des branches à des cas bien spécifiques.
Avec des outils Git-like (comme Mercurial) il n'y a pas lieu de s'imposer de telles limitations.
Les différences de pratiques sont la conséquence des différences de fonctionnement et de fonctionnalités entre ces catégories d'outils, qui se résument à "Centralisation" pour SVN-like et "Distribution" pour Git-like.
Déjà , le concept même de distribution impose l'utilisation de branches. Un clone de repository Git s'utilise pratiquement de la même façon qu'une nouvelle branche. Un pull sur un clone n'est rien d'autre qu'un fetch suivi d'un merge, c'est à dire exactement la même commande utilisée pour une branche.
Et puis, il suffit d'avoir expérimenté l'utilisation d'un rebase Git, sans équivalent sous SVN, pour comprendre qu'on a changé de catégorie. En gros le rebase, c'est l'outil qui permet de retrouver une arborescence "pure" comme celles présentées par FKDEV, quel que soit l'historique réel des branches.
Bonjour,
Intéressant sujet même si cela me semble compliqué (mais j'ai lu rapidement et en diagonale).
Y-a-t-il un intérêt à utiliser de tels systèmes pour un développeur amateur et seul ?
Bien sûr je sauvegarde régulièrement mon travail.
Je ne suis pas amateur, mais je développe seul la plupart du temps, et je t'assure que c'est utile.
Par exemple, comment fais-tu pour conserver les anciennes versions ? Tu dupliques le dossier dans le Finder et tu le renommes ? C'est une perte de temps, et en plus ça ne te garantit pas que tu ne le modifieras pas par inadvertance.
L'autre avantage courant, c'est qu'on veut tester un truc, sans savoir si vraiment ce sera intégré dans l'appli finale. La gestion de version permet de rejeter finalement des modifications.
J'ai pas voulu dire ça.
J'ai voulu dire que le principe du tofu-scale est indépendant du type d'outil. D'ailleurs on le retrouve dans git-flow (même si dans git-flow, il y a en plus une distinction master/develop pour tricher avec les nightly builds mais bon...).
Il y a des principes de qualité logiciels qui sont indépendants des outils, je pense que c'en est un.
Attention, Perforce est quand même plus riche que svn, même si les branches restent plus complexes sont Perforce que sous git.
Si par "cas bien spécifiques", tu entends "quand on en a vraiment besoin", alors je suis d'accord.
Le fait est que pour les équipes sédentaires, une fois passée l'euphorie de faire des branches dans tous les sens, on revient à un système centralisé où les branches doivent être organisées sinon c'est le bazar.
J'avoue que je ne connais pas bien le rebase, mais si cela permet de nettoyer tout le bazar créé par des branches anarchiques, j'ai envie de dire pourquoi créer des branches anarchiques ? Pourquoi ne pas suivre le modèle git-flow (ou tofu scale) dès le départ...
C'est un peu comme l'euphorie de passer à un langage non typé, genre php, puis de se réveiller le lendemain avec des '===' et des '==' dans son code. wtf?
Toute flexibilité à un revers et on finit par créer des conventions pour maitriser les développeurs.
Sur le fond, j'ai rien contre git, je dis juste que quand on travaille en équipe à 4 ou 5 dans le même bureau, pour un client qui a des délais, ben on a besoin de conventions... surtout si l'outil est très flexible.
Et pour les branches centralisées, git-flow/tofu est une des meilleures conventions que j'ai vu.
Après pour les développement open-source, je pense que la flexibilité de git est un grand progrès mais les méthodes sont nécessairement différentes des méthodes pour équipes sédentaires.
Sans même parler de branches, c'est mieux d'utiliser un système de gestion de conf. même si on est seul.
Tu peux facilement faire des diffs ou revenir en arrière sur un seul fichier par exemple.
Si tu utilisez une méthode à base de fichiers zip, tu passes plus de temps à gérer des backups 'idiots' avec lesquels tu ne peux pas faire de diff.
Si tu utilises un serveur ou github, tu pourras faire des backups distants en un clin d'oeil.
D'abord tu peux n'utiliser que la branche master et ensuite, quand tu es à l'aise, tu peux utiliser des branches expérimentales comme indiqué par Céroce.
J'espère que tu ne deviendras pas un traà®tre à tes propres idées comme moi (j'ai honte >:D )
Pendant de nombreuses années j'ai enseigné les bonnes pratiques "regular", celles que tu cites FKDEV, en me basant notamment sur l'excellent livre "Software Configuration Management Patterns" de Berczuk & Appleton.
Et un jour j'ai eu besoin de gestion distribuée ...
Je vais dans le sens de mes collègues, c'est très utile même pour un dev solo.
Faire une branche par feature (chose impensable sous SVN alors qu'idéal sous GIT) quand tu commences une feature, c'est pratique pour voir clairement dans ton historique ce qui s'est passé et pouvoir revenir en arrière en cas de soucis.
Par exemple tu commences à bosser sur une killer-feature-1 donc tu fais une branche, tu y passes plusieurs jours, tu fais plein de commits au fur et à mesure que tu avances dessus et passe des étapes pour intégrer cette feature, puis une fois que tu l'as finie, tu merge la branche killer-feature-1 dans ta branche principale (master).
Puis tu bosses sur une killer-feature-2, et rebelotte. Puis une killer-feature-3.
Et puis un jour tu veux supprimer tout ce que tu as fait sur killer-feature-1. Si tu n'as pas fait de branche, va retrouver les commits (où ça commence et où ça finit) concernant cette feature... alors que si tu as bien fait des branches tu vois où commence ta suite de commit pour cette feature, et où ça finit.
Sans parler du tagage pour marquer/sauvegarder des versions, pouvoir revenir en arrière, faire de la dicotomie quand tu as besoin d'isoler un bug ou une régression... y'a vraiment des avantages intéressants
Merci pour vos réponses très instructives.
Le système de branche me semble très intéressant.
Je fais chercher quelques tuto pour pouvoir essayer.