Git next et Git prev, pour vos tutos | Sam & Max: Python, Django, Git et du cul

Git next et Git prev, pour vos tutos

Il peut être pratique de fournir un repository Git plein de code à télécharger dans un tuto. Parfois le code a plusieurs états, comme autant d’étapes que vous voulez que le lecteur découvre au fur et à mesure.

Voici un petit alias Git qui permet de faire exactement cela. Mettez dans votre fichier ~/.gitconfig :

[alias]
    prev = checkout HEAD^1
    next = "!sh -c 'git log --reverse --pretty=%H master | awk \"/$(git rev-parse HEAD)/{getline;print}\" | xargs git checkout'"

Et votre lecteur pourra juste faire :

git next
git prev

Pour passer au commit suivant ou précédent dans votre repo, comme un wizard. Vous pouvez alors dans votre tuto parler du code dans un état donné, puis lui demander de faire git next, puis parler du nouvel état du code, etc.

  16 comments for “Git next et Git prev, pour vos tutos

  1. 23/01/2013 at 05:55

    Je n’ai jamais compris git :/ snif.

  2. 23/01/2013 at 06:11

    Super cette astuce !
    Même si les dépots git liés à des tutos n’ont parfois qu’un seul commit “First commit”

  3. Sam
    23/01/2013 at 07:46

    @JeromeJ : je me tate à faire un bon tuto sur la question. Mais c’est looooooooooooooooooooooong.

  4. Krypted
    23/01/2013 at 13:21

    Ah en tout cas un tuto sur Git serait vraiment le bienvenu !

  5. 23/01/2013 at 14:40

    Ha ce Git!! l’outil du siècle :)

    Mais comment faites-vous pour écrire autant de tutos, d’articles !! vous avez un débit impressionnant, et de qualité en plus :p

    Avouez, vous n’êtes pas humains :p
    Bonne continuation .
    Ch.

  6. Sam
    23/01/2013 at 15:43

    On est des bots codés avec des chaînes de markov calibrées sur le site du zéro.

  7. roro
    24/01/2013 at 04:42

    Hey Sam, toi qui est prof, aurait-tu quelque chose à dire ? Sur le thème: Apprentissage par le cours magistral, versus apprentissage par l’exemple. Caractéristiques, singularités. Qu’est-ce qu’un exemple?

  8. 24/01/2013 at 05:02

    dans le style tuto bien foutu sur le workflow de release/branch :
    A Successful Git Branching Model

  9. Sam
    24/01/2013 at 05:52

    @roro : non j’ai rien a dire sur la question qui n’ai pas déjà été dit et redit.

  10. roro
    24/01/2013 at 06:48

    @Sam : Qui me dit: ” Non j’ai rien a dire sur la question qui n’ai pas déjà été dit et redit.”
    Normal. C’est pour cela que pour homologuer un nouveau système de freinage il faut passer par les essais sur route.
    Pour être plus clair: Je vais à l’article: “Comment améliorer la communauté python francophonne”.
    Là, je fais un copié/collé dans le bloc-note de Windoze, de:
    1)- “Le bout de code de Guido VR”, et
    2)-“Le mème bout commenté par Max”.
    J’ouvre le shell, j’y colle le premier: ça marche; j’y colle le deuxième, ça marche pas. (indentation)
    Tout ça pour dire, que l’exemple “véritable” est la meilleure, (je n’ose pas dire la seule) façon de valider un code.
    D’où la question: qu’est-ce qu’un exemple ?

  11. Sam
    24/01/2013 at 07:19
  12. roro
    24/01/2013 at 10:24

    Et bien c’est simple; c’est un truc qui donne la preuve que le code fonctionne.
    D’où la nécessité de disposer d’une sorte de banc d’essai réutilisable,dans lequel on pourra inclure un bout de code et tester son fonctionnement.
    Ce “banc” pouvant de plus, servir de base de départ à des projets, quitte à en élaguer l’inutile.
    Il y a longtemps que je me suis bricolés de tels bancs ( mais ils sont dans un langage dont la seule évocation est honteuse, pour les élites de la prog.)

  13. Sam
    24/01/2013 at 10:34

    Ca exclue le pseudo code, le cas d’école, l’idée théoerique en général. Le problème avec cette idée c’est qu’elle exclude les cas complexes qui ne peuvent pas se représenter par un simple snippet applicable. Il nie aussi la relation qu’il y a entre plusieurs bouts de code, qui peut être ce que l’exemple veut illustrer.

    C’est pour ça que je n’ai pas voulu me risquer à répondre cette question, c’est parceque je ne pense pas pouvoir y répondre sans dire une contre vérité.

  14. roro
    24/01/2013 at 10:39

    Et c’est pourquoi, je ne développe pas en python à partir de zéro.
    Je préfère bricoler sur des codes existants, et fonctionnels, même si ce sont parfois des trés gros morceaux.
    Comme le code fonctionne, je peux tester mes modifs, “in situ”.
    Parce qu’en prog, on a beau savoir ce qu’on fait, on fini toujours, à un moment, par avancer à l’intuite”, et c’est là que les soucis commencent.

  15. roro
    24/01/2013 at 11:11

    Un banc d’essais peut être simple, complexe, ou non réalisable; en fonction de ce qu’on a à tester.
    Et vu la poly(morphie!?!) du python, de tels bancs ne sont pas évidents à concevoir.
    Cela reste un bel exercice d’imagination.

  16. 19/09/2013 at 20:00

    Un truc qui marche bien aussi c’est utiliser les branches/pull-request pour faire des tutoriaux:
    https://github.com/leplatrem/django-leaflet-geojson/pull/1/files

Leave a Reply

Your email address will not be published. Required fields are marked *