[Git] Comment s'y prendre pour un changement de version majeure ? - Page 1

yop,

J'ai un projet sur Github, j'ai fini la première version : https://github.com/Folcogh/FMetro

Je veux bosser sur une seconde, mais qui repartira à 80% from scratch. Cependant, j'ai pas envie de changer de nom, je veux garder le même repo, mais tout en continuant à maintenir la version 1 telle qu'elle est (bugfix et modifs mineures).

Alors comment ça se fait, concrètement, avec Git ?

Est-ce que je dois créer une branche avec ma version 1 actuelle, et garder la branche master pour la version 2 ?

Est-ce que j'aurais dû organiser mon arborescence autrement, dans mon dépôt Git ? Parce que là, j'ai du mal à voir ce que ça va donner, concrètement sur mon disque dur, si je checkout la branche 1.0 et la branche master.
S'il y a des changements profonds à apporter, je préfère autant les faire maintenant !

Je ne vous cache pas que Git est surpuissant par rapport à mes besoins, et que me plonger dans la doc pour en découvrir les arcanes, loin de me conseiller sur un choix de ce genre, m'a plutôt perdu dans les méandres du logiciel, sans que je saisisse bien les tenants et aboutissants des différentes possiblités.

Merci d'avance pour vos conseils

Folco

Tu crées une branche 1.0, elle héritera automatiquement toute l'historique de ton actuel master. (Au moment du branchement, 1.0 et master seront exactement la même chose.) Après, tu fais ce que tu veux avec master.

Et pour avoir 2 checkouts, la solution conseillée par les développeurs de git: https://git-scm.com/docs/git-worktree
(Tu peux aussi avoir 2 clones séparés, mais ça fera 2 fois la consommation de place, ou alors tu peux travailler avec une seule copie de travail et switch-branch.)

Merci beaucoup

Attention, git worktree est apparemment nouveau dans Git 2.5 qui vient de sortir il y a 3 semaines.

Avant, il y avait git new-workdir, mais seulement sur *nix (car dépendant de liens symboliques).

C'est grave de pas avoir des répertoires head/trunk/branches/... ?
Ca va être automagiquement créé par Git, ou c'est à moi de créer cette arborescence de base, qui semble relativement standard ?

Folco (./6) :
C'est grave de pas avoir des répertoires head/trunk/branches/... ?Ca va être automagiquement créé par Git, ou c'est à moi de créer cette arborescence de base, qui semble relativement standard ?

Ce n'est pas grave, c'est même normal ^^

Tu n'as pas à te préoccuper de ça avec git, c'est transparent.

Les branches ne fonctionnent pas comme avec SVN. Globalement, dans svn, les branches sont deux dossiers différents, et tu bascules d'une branche à l'autre en changeant de dossier.
Avec git, tu auras un seul dossier pour toutes les branches, avec une seule branche active en même temps.

Changer de branche active modifie les fichiers présents dans ton dossier.

Ok merci !

Pour un petit projet je trouve worktree overkill, c'est pas gênant de checkout entre deux branches. Quand ton code fait 700 Mo, c'est une autre histoire.

(Certes il reste le problème du code unstaged, mais personellement je m'en sors très bien avec un bon vieux git stash, ou même une commit temporaire que j'amend jusqu'à ce qu'elle soit bonne pour un push si je suis seul sur un projet)

Question de préférences je suppose.

Je te conseille aussi de marquer ta révision 1.0 avec un tag, elle apparaîtra comme une "pseudo"-branche sur GitHub.

Et si tu veux voir les entrailles de ton dépôt, tout est dans le .git à la racine du dépôt

J'ai rien compris. Je fais juste "clone" pour créer un dépot local, "commit" pour committer dedans, et "push" pour sauver en ligne. Dans un gui bien sûr. Le but, c'est d'avoir une sauvegarde sur internet si mon disque du pète, le reste je m'en fous

Bah du coup le plus simple est de faire comme suggère Kevin, tu conserves une référence vers ta version 1.0 (soit une branche, soit juste un tag dessus, dans les deux cas ça sera facile de la récupérer en cas de besoin) puis tu peux continuer à utiliser "master" pour ton développement. Si c'est une réécriture from scratch peut-être que tu ne voudras même pas garder l'historique de la version 1.0, auquel cas tu peux utiliser l'option --orphan de la commande git checkout pour créer une nouvelle branche vierge.

Bon eh bien, j'ai créé une branche 1.0, puis j'ai quasiment tout effacé, j'ai recommencé un projet par dessus. Ca marche du tonerre, je peux switcher d'une branche à l'autre, c'est transparent pour moi
Ah, et j'ai essayé Git stash aussi, ça a certainement un intérêt pour certains, mais probablement pas pour moi. Mais j'imagine que ça doit plus servir dans un environnement pro.

Sinon, sous KDevelop, je peux commit (donc su mon dépôt local, si j'ai bien compris), mais pas pusher. Etonnant, j'y arrive avec Tortoise Git, GitTk, sans problème. Là, il me sort ça :

/mnt/Data/prog/FMetro> git push
Command exited with value 128.
warning: push.default n'est pas défini ; sa valeur implicite a changé dans Git 2.0
de 'matching' vers 'simple'. Pour supprimer ce message et maintenir
le comportement actuel après la modification de la valeur de défaut, utilisez :

  git config --global push.default matching

Pour supprimer ce message et adopter le nouveau comportement maintenant, utilisez :

  git config --global push.default simple

Quand push.default vaudra 'matching', git poussera les branches locales
sur les branches distantes qui existent déjà avec le même nom.

Depuis Git 2.0, Git utilise par défaut le comportement plus conservatif 'simple'
qui ne pousse la branche courante que vers la branche distante correspondante
que 'git pull' utilise pour mettre à jour la branche courante.
 
Voir 'git help config' et chercher 'push.default' pour plus d'information.
(le mode 'simple' a été introduit dans Git 1.7.11. Utilisez le mode similaire
'current' au lieu de 'simple' si vous utilisez de temps en temps d'anciennes versions de Git)

fatal: could not read Username for 'https://github.com': No such device or address

Command finished with error UnknownError.

Alors je veux bien créer le fichier qu'il veut et y écrire ce qui lui fera plaisir, mais j'aimerais savoir avant pourquoi :
- il ne trouve pas l'adresse du dépôt d'origine (c'est bien ça ?), alors que je'ai cloné directement de là-bas
- les autres softs qui travaillent sur ce repo n'ont pas de souci pour pusher

Ce dont j'ai peur, c'est de faire qqchose d'irréversible en créant un fichier qui irait foutre le boxon sur le repo d'origine, et me ferait perdre des données. Sachant aussi que comme je connais pas git, et qu'il est un tantinet complexe (suffit de voir la tronche du message qu'il me sort pour une pauvre url qui lui revient pas), je préfère demander.

Merci d'avance ^^

Tu n'as pas d'upstream on dirait. Quand tu creés une branche, la première fois fais un :
git push -u origin branche
Le -u la définit comme upstream, c'est à dire que tu peux pusher de façon transparente (sinon elle reste locale, ça t'évite de faire des conneries). Ensuite tu pourras te contenter de git push.

Sinon marrant que vous conseilliez de faire une branche pour la 1.0. C'est un détail mais le contraire me semble plus logique : tu fais une branche 2.0, tu tagues le master comme 1.0 au moment de la release et tu commences à travailler sur la branche 2.0. Quand la v2 sera aboutie et deviendra une référence tu la mergeras sur master. Si tu dois continuer de travailler sur la v1 tu branches à partir de là.

(Justement, j'ai demandé car je ne savais pas quelle méthode choisir )

Sinon, que veux-tu dire par "je n'ai pas d'upstream" ? Je travaille sur la branche master (le nom par défaut, j'imagine), que j'ai déjà pushée un certains nombre de fois sur github avec Gitk ou Tortoise Git : ils me demandent mon nom/pwd et ça marche.

Par contre, en ligne de commande, "git push" me renvoie la même erreur que KDevelop. Alors comment font les autres softs ?

Ils spécifient origin/master comme destination explicitement.

ok, donc je vais devoir le faire aussi. Faut juste que je comprenne bien le message d'erreur. (je haie les geeks qui se croient obligés de pondre des messages où ils réinventent la rouent, fournissent un exemplaire du larousse où ils ont vérifié la définition exacte de chaque mot, dans un souci de rigueur extrêmiste qui rend leur jargon absolument imbitable )

Avoir une branche "upstream", ça veut dire que tu as associé une branche distante (sur un certain remote donc) à ta branche locale. Par exemple, tu peux configurer ta branche "master" pour que son upstream soit "master" sur le remote "github" (en général on donne le même nom à la branche locale que la branche à laquelle elle correspond sur le remote, sinon c'est le bordel). Ensuite tu peux configurer la commande git push pour que par défaut, sans argument, elle pousse la branche courante vers la branche upstream correspondante (je crois que ça n'est pas la configuration par défaut, je me trompe peut-être, si besoin ça se configure en faisant git config --global push.default upstream ou qqchose du genre). Pour rester dans mon exemple précédent, ça veut dire que taper git push quand tu es sur ta branche master va la répliquer sur github dans la branche master.

[edit] je n'avais pas vu que le message d'erreur contenait justement la bonne configuration à spécifier pour pousser automatiquement sur la branche upstream

Ok, merci beaucoup, ça m'a permis de comprendre. J'imagine qu'il y a un intérêt d'avoir des branches identiques avec deux noms différents, mais je sais pas lequel ^^ probablement pour des très gros projets, partagés un peu partout. En attendant merci beaucoup.

Ah non c'est différent. Tu peux effectivement avoir deux branches identiques avec deux noms, mais ici il ne s'agit pas de ça, il s'agit d'avoir une branche locale que tu considères comme l'image d'une branche distante, pour pouvoir synchroniser plus facilement l'une avec l'autre sans avoir à taper leur deux noms à chaque fois (la commande "git push" complète, c'est git push <remote> <ref locale>:<ref distante>, par exemple git push origin master:master, ça devient très vite pénible à taper en entier donc un raccourci est le bienvenu ^^)

Yep. J'avais compris, mais j'étais plus épaté par le coup de la branche qui a deux noms suivant le site que par l''explication de mon problème, mais en tout cas merci.

Bon, ça fait un truc de plus qui fonctionne bien dans KDevelop, et ça c'est cool.

Forcément. C'est pas l'environnement préféré de Kevin pour rien KDevelop !