[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: versioning system (VCS)



Le 30 avril 2011 18:12, Jean-Yves F. Barbier <12ukwn@gmail.com> a écrit :
> On Sat, 30 Apr 2011 17:57:47 +0200, Rémi Vanicat <vanicat@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: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/


Reply to: