Le 30 avril 2011 18:12, Jean-Yves F. Barbier <12u...@gmail.com> a écrit : > On Sat, 30 Apr 2011 17:57:47 +0200, Rémi Vanicat <vani...@debian.org> wrote: > > ... >> git checkout permet de revenir à n'importe qu'elle version du fichier: >> $ git checkout commit -- file >> récupère le fichier file dans la version ou il se trouvait à l'époque du >> commit "commit" (on parle de commit avec git plus que de révisions). > > Ha, meilleur! > Pour être sur d'avoir bien compris: > $ git checkout a8445d2551ca45ef -- monfichieramoiquejeveuxdanscecommit > et ça roule? > >> En plus git possède des interfaces graphique comme gitk ou giggle qui >> permette (entre autre) de ne regarder que les commits où un certain >> fichier a évolué. > > Je n'avais testé que gitk, je vais retester avec giggle
Il y a aussi gitg (rapide) et beaucoup d'autres pour environnement KDE. A noter le fameux tig : un navigateur Git en curses, c'est à dire une interface graphique textuelle. Il est extrèmement rapide. Concernant l'exploration de l'historique d'un seul fichier, beaucoup d'outils reprennent les principes des outils de ligne de commande de Git : _ma_commande_git_ --- mon/fichier Par exemple, tig fonctionne ainsi. >> > Je tâtonne souvent et je crée des tas de versions différentes d'un >> > fichier; à la fin, soit le fichier final correspond à mes attentes, soit >> > je pioche dans plusieurs pour obtenir le final - C'est toute cette chaîne >> > que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me trompe >> > ptêt: cette partie du dev est peut-être uniquement du ressort personnel et >> > pas du système de VCS?) >> >> git permet certainement de faire ça. Dans ce genre de cas ma méthode est >> de faire 36 branches correspondants au différentes idée que j'ai pour >> résoudre le problème, et je choisi celle qui me va à la fin, mais c'est >> certainement pas la seul façon de faire. > > ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de > toutes les modifs d'un fichier jusqu'au commit final) En fait, il faut voir Git comme un outil de très bas niveau. Linus lui même se défend d'avoir créer un VCS, plutôt un outils pour construire de VCS. Ainsi, la très grosse difficulté de Git correspond à la question que tu as posé à très juste titre : de quelle manière est-ce que je vais utiliser Git pour améliorer mon organisation. Pour cela, malheureusement, il faut à la fois connaître Git et être clair sur ton organisation actuelle. Ensuite, tu peux utiliser Git comme il faut. Bref, tout ça pour dire qu'il faut certainement que tu te lances dans l'aventure, pour essayer, découvrir. Et surtout, fait des sauvegardes avant de lancer des commandes dont tu doute du résultat. Pour les sauvegardes, tu peux faire des "git clone" pour copier tout l'historique, ou simplement des "git archive" pour garder un instantané de ton projet. Enfin, sans remettre en doute la compétence des inscrits à cette liste, si l'anglais ne te dérrange pas trop, je t'invite à aller sur la liste de discussion de Git. Malgré son nom en "devel" c'est sur cette liste que le support est apporté aux nouveaux. Bon courage. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinwe00VbrQVqxnEGYc3=_9jyge...@mail.gmail.com