Journal Tutorial GIT

Posté par  (site web personnel) .
Étiquettes : aucune
17
6
oct.
2009
Bonjour tout le monde,

A la demande de mon ami Pierre Schambacher, j'ai écrit un petit tutoriel sur GIT. En fait c'est surtout un retour d'expérience de 6 mois qui m'a permit de tester beaucoup de ses possibilités. Hélas j'ai travaillé tout seul donc il manque l'aspect collaboratif (je ne voulais y mettre que ce dont j'étais vraiment sûr). Si vous avez des remarques, des questions ou des améliorations (une version PDF sera bientôt disponible), n'hésitez pas à les poser ici ou là bas. Bonne lecture !

http://www.pierreschambacher.com/blog/git-in-a-nutshell/

  • # Et le wiki alors ?

    Posté par  (site web personnel) . Évalué à 8.

    Hélas j'ai travaillé tout seul donc il manque l'aspect collaboratif

    Il existe le Git Community Book :
    http://book.git-scm.com/

    Je l'ai imprimé en version PDF et il est très bien :
    * bonne introduction avec le « système de fichiers git » (la manière dont sont stockées les données)
    * difficulté progressive
    * jolis schémas qui expliquent bien
    * présente de très nombreuses fonctionnalités

  • # Git c'est bon menjézan !

    Posté par  . Évalué à 6.

    Hello,

    Ton tuto est intéressant, mais j'aurais quelques remarques :


    Tout d’abord qu’est ce que git ?! Et bien avant d’être un logiciel de gestion de versions décentralisé (ou DSCM pour Distributed Source Code Management) il a été conçu comme un système de fichiers avec un système de versionning, le tout construit pour la performance.
    Là si ça s'adresse à des débutants et des gens sous Windows, tu as probablement déjà perdu 90% de tes lecteurs.

    Pourtant simple à utiliser et performant : tout est instantané ! Pas exactement. S'il est vrai que c'est sensiblement plus rapide que les autres SCM/RCS, il y a une petite exception : le git add est particulièrement plus long que les autres (particulièrement sur un volume de sources important).

    Il est recommandé pour la bonne compréhension de cet article de connaitre SVN. Franchement, mieux vaut ne pas avoir pris des mauvaise habitudes avec svn quand on se met à git, ça permet de commencer sans mauvais a priori.

    On entend par décentralisé le fait de pouvoir « commiter » et faire évoluer un bout de code en local indépendamment d’un serveur central (comme dans le cas de svn), Je pense qu'il faudrait reformuler. À la première lecture, j'ai compris que svn était distribué. Je verrais plutôt quelque chose comme « en local, contrairement à svn qui nécessite un serveur central ».


    Sur la partie sur la bissection peut être aurait-il fallu préciser que c'est un outil puissant qui permet de retrouver rapidement une erreur grâce au tri dichotomique (diviser pour régner pour expliquer aux lecteurs pas tout à fait au point en algorithmie).


    Pour la conclusion : Le terminal … ça va bien un moment mais on aime aussi avoir un client graphique un peu plus convivial qui fait le boulot pour nous !
    Heu franchement, non.

    (Dommage qu'on ne soit pas vendredi, j'aurais bien dit que ce n'est pas étonnant que tu fuie l'édition CLI vu que tu utilise emacs, mais aujourd'hui, c'est mardi, je n'ai pas le droit).

    • [^] # Re: Git c'est bon menjézan !

      Posté par  (site web personnel) . Évalué à 3.

      Merci pour tes remarques,

      Mon tutorial ne s'adresse pas aux débutants (peut être que j'en ferais un cours complets plus tard ...), en effet il faut avoir des notions de gestion de version (svn pour le plus connu).

      J'exagère un peu en disant que tout est instantané, mais c'est vraiment l'impression qu'il donne quand on fait un git add (dont le fichier ne fait pas 400Mo), idem pour les autres commandes. J'ai eu à manipuler ClearCase et SVN ... en comparaison git est effectivement instantané.

      La conclusion du terminal n'est pas de moi, elle est surtout là pour proposer des clients graphiques pour Git, personnellement je fait tout en ligne de commandes (et avec emacs :p)


      PS : Le tuto a été mis à jour

      • [^] # Re: Git c'est bon menjézan !

        Posté par  (site web personnel) . Évalué à 3.

        Pour moi, gitk et git gui (ou git citool) me suffisent comme interface graphique.

        Certaines opérations sont plus faciles avec une interface graphique (voir l'historique, choisir exactement les lignes qu'on veut commiter (git add -i), ...) mais d'autres sont bien plus faciles en ligne de commande.

    • [^] # Re: Git c'est bon menjézan !

      Posté par  (site web personnel) . Évalué à 4.

      Le terminal … ça va bien un moment mais on aime aussi avoir un client graphique un peu plus convivial qui fait le boulot pour nous !
      Heu franchement, non.


      Ca commence à devenir pénible, cette guéguerre éternelle et stupide. Je suis fan de la ligne de commande, je fais presque tout avec, mais pour certaines tâches, il est sympa d'avoir une interface graphique.

      La question n'est pas de savoir si les GUI sont supérieures aux CLI ou l'inverse, mais de savoir, pour une tâche précise dans une situation précise quelle solution ME convient le mieux.

      hop, problème résolu.

    • [^] # Re: Git c'est bon menjézan !

      Posté par  . Évalué à 0.

      mieux vaut ne pas avoir pris des mauvaise habitudes avec svn quand on se met à git,

      Je sens que je vais aimer ce troll, à condition que tu précises un peu tes arguments...

    • [^] # Re: Git c'est bon menjézan !

      Posté par  . Évalué à -1.

      oui un bon gui manque vraiment à git, et une bonne intégration dans des outils comme eclipse. L'essentiel étant de savoir ce qu'est capable de faire git et pas de se rappeler les commandes alacon (je déteste avoir à mettre un "shitlist" à coté de mon écran pour me rappeler comment checkouté depuis un repo distant)...
      C'est ce qui me fait rester sur svn, malheureusement.

      Gaetan

      • [^] # Re: Git c'est bon menjézan !

        Posté par  (site web personnel) . Évalué à 3.

        > C'est ce qui me fait rester sur svn, malheureusement.

        si tu reste à svn uniquement parce que tu le connais et que tu ne connais pas git, oui c'est vraiment malheureux..

        git / mercurial / bazaar sont tous bien plus complet que svn, il est donc évident que pendant un temps il faudra apprendre, se tromper (un peu), lire doc / man (beaucoup) et ensuite ça rentre vite tout de même
        git est surement le plus éloigné de svn, ce qui peut pour certains compliquer la tâche. Pour moi c'est au contraire un atout si on accepte de ne plus faire les choses de la même manière (en même temps pour les derniers moi j'ai utilisé svn - tous les jours - git - assez souvent - mercurial et bazaar, finalement on se rend compte que pour beaucoup de chose c'est uniquement un nom de commande / une option inversée qui change, le principe lui reste le même, après faut savoir être souple)

        Sinon, concernant les gui, egit/jgit a repris un développement un peu plus actif désormais, à voir ce que ça va donner, prochaine release début 2010 (toujours sans merge, branches, etc, donc pour moi inutilisable mais bon...) -> http://eclipse.org/egit

  • # git-foo Vs git foo

    Posté par  (site web personnel) . Évalué à 5.

    La syntaxe git-foo est la forme dépréciée de git foo (sans tiret). Les commandes avec tirets ne sont plus installées dans le $PATH depuis la 1.6.0, autant ne pas les mentionner du tout dans un tuto.

    • [^] # Re: git-foo Vs git foo

      Posté par  . Évalué à 3.

      s/ dépréciée / désapprouvée|à éviter|déconseillé /

      Deprecate : 1. religieux, « prier contre », voir le français « déprécation », 2. plus généralement, désapprouver, déconseiller.

      Ça n’a (notamment étymologiquement) rien à voir avec un abaissement de la valeur (= déprécier).

      Sur ce →[]

  • # HEAD~n : le nième parent de HEAD

    Posté par  (site web personnel) . Évalué à 2.

    > HEAD~n : le nième parent de HEAD

    => pas vraiment. C'est l'ancètre de N-ième génération (i.e. le grand-grand-grand-....-père).

    Le nième parent, c'est plutôt HEAD^n (vu qu'un commit peut avoir plusieurs parents en cas de merge).

  • # Error establishing a database connection + Quelques sources

    Posté par  (site web personnel) . Évalué à 2.

    Tu dois avoir un petit soucis sur ton blog, cf le titre.

    Je me permets d'ajouter ici deux sources que je trouve de grande qualité :

    http://www.unixgarden.com/index.php/administration-systeme/g(...)

    http://www.unixgarden.com/index.php/administration-systeme/g(...)


    Il s'agit de deux articles de GLMF. Bonne lecture

    Alexandre COLLIGNON

  • # lawsuit in a nutshell

    Posté par  . Évalué à 2.

    Tu ne risques pas d'avoir quelques soucis avec un éditeur d'ouvrages techniques réputé ?

    • [^] # Re: lawsuit in a nutshell

      Posté par  . Évalué à 2.

      dans la mesure où "in a nutshell" est une expression anglaise courrante ça m'étonnerai beaucoup.
      regardes les resultats gogole pour "in a nutshell".
      http://www.google.fr/search?hl=fr&q=in+a+nutshell&bt(...)

      • [^] # Re: lawsuit in a nutshell

        Posté par  . Évalué à 3.

        Oui et je vois la série du grand éditeur en question en 3e position, ce qui n'est pas vraiment rassurant.

        L'auteur aurait pu faire preuve d'imagination en choisissant un autre titre comme je sais pas, par exemple [troll inside] Git for Dummies[/troll inside]

        • [^] # Re: lawsuit in a nutshell

          Posté par  . Évalué à 7.

          git & emacs in a coconut...

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.