Objet : Liste de discussion du groupe de travail Éducation et logiciels libres de l'April (liste à inscription publique)
Archives de la liste
- From: Gérard Vidal <gerard.f.vidal AT gmail.com>
- To: educ AT april.org
- Subject: Re: [EDUC] Github/Edu
- Date: Mon, 16 Apr 2018 16:43:14 +0200
- Authentication-results: vip.april.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i= AT gmail.com header.b="Sbggh0P2"; dkim-atps=neutral
Bonjour, je crois aussi que git est une solution à envisager pour l'éducation même si mes expériences actuelles avec les enseignants sont plutôt décevantes :'(. je pense qu'il faut tout de même être prudent car git a tendance à entraîner ses utilisateurs vers des usages complexes (syndrome du tout est possible tout est réalisable..); je ne pense pas qu'on puisse utiliser git avec une classe si on n'est pas soi même impliqué dans un travail collaboratif utilisant un outil git (ou mercurial). La notion de travail collaboratif (au vrai sens complet du terme) est facile à comprendre et à mettre en œuvre techniquement mais beaucoup moins facile à vivre au quotidien...;-) Un peu comme la notion de bien commun à laquelle elle est fortement liée d'ailleurs. je souscris à ce qui est dit sur l'alibi sécuritaire qui envahit
le second degré et conduit à une stérilisation complète des
usages, ce qui requiert que nous puissions proposer des stratégies
alternatives. Même si cela requiert quelques compétences je crois qu'il ne faut pas évacuer d'office un serveur interne (surtout si on envisage une innocente raspberry O:-)). Il existe quelques outils libres proposant des interfaces plus ou moins conviviales et configurables qui pourraient être déployés interne juste pour une classe ou un projet. Dans le monde python kallithea peut rendre des services et permet d'avoir une sorte de github privé en interne et d'organiser le travail autour d'un flux principal (mainstream) avec une ou deux branches et un ensemble de flux secondaires (forks) permettant à tous de voir le travail de chacun et à chacun de faire remonter ses contributions. Bon travail PS : si le codage en utilisant une interface web fournie par une
raspi vous intéresse voici la partie github du travail
https://github.com/g-vidal/CahierDeProgrammes Le 16/04/2018 à 15:51, Grégory Mounié a
écrit :
Bonjour
Je ne suis pas exactement dans le même cas (mes 250 étudiants ont 20 ans, une moitié aimant les math, une moitié aimant l'info, en début d'école d'ingénieur, et ils ont fait 10h d'UNIX avant de voir git) mais je pense que c'est une excellente idée. - Git est au final facile à apprendre en 1h30 parce que finalement il n'y a que deux concepts: enregistrer localement des changements (add, commit) et déplacer des changements entre deux machines (push, pull). - En 1h30, ils arrivent *tous* à utiliser git et créer leur propre dépôt (sur une machine avec ssh) en 1h30. Le seul raccourci que nous utilisons à ce moment là est de faire "git commit -a" plutôt que d'expliquer l'index. Nous faisons un TP pas à pas (création, clone, édition, fusion, édition, fusion, etc.), en équipe de 2-3. Le faire en équipe est important pour qu'ils voient l'intérêt. - En utilisant gitlab, la création/clonage devient triviale (click, taper un nom, click, copy-paste, enter, done). Avec juste ssh, nous sommes plutôt de l'ordre de 15-30 minutes sur ce seul point, en donnant les commandes à taper. - Il y a un support git dans tous les bons éditeurs (et quelques mauvais) mais pour des débutants je trouve plus simple pour eux de tout faire en ligne de commande pour bien comprendre les concepts, le vocabulaire et ne pas les mélanger avec ceux de l'édition. Un point sur lequel nous insistons est qu'ils arrêtent les échanges par email/USB car cela cache des changements à git et du coup augmente leurs conflits de fusions. Bon cours Grégory PS: Pour Mercurial, qui est aussi un bon choix, il y a longtemps, "l'interface" était plus simple que celle de git, mais ce n'est plus vrai, et sur le fond le concept des têtes multiples de Mercurial reste pénible à manipuler et à expliquer à des débutants. Le 15/04/2018 à 12:19, William Gambazza (wgambazza AT yahoo.fr via educ Mailing List) a écrit : Le 15/04/2018 à 12:07, Marc Ferraton (marc.ferraton AT laposte.net via educ -- Pour vous désinscrire de cette liste : https://listes.april.org/wws/sigrequest/educ Pour connaître la configuration de la liste, gérer votre abonnement à la liste educ et vos informations personnelles : http://listes.april.org/wws/info/educ |
- Re: [EDUC] Github/Edu, (suite)
- Re: [EDUC] Github/Edu, Romain, 14/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 14/04/2018
- Re: [EDUC] Github/Edu, Marc Ferraton, 14/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 14/04/2018
- Re: [EDUC] Github/Edu, Marc Ferraton, 15/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 15/04/2018
- Re: [EDUC] Github/Edu, Eric Guirbal, 15/04/2018
- Re: [EDUC] Github/Edu, Marc Ferraton, 15/04/2018
- Re: [EDUC] Github/Edu, David Chemouil, 16/04/2018
- Re: [EDUC] Github/Edu, Grégory Mounié, 16/04/2018
- Re: [EDUC] Github/Edu, Gérard Vidal, 16/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 16/04/2018
- Re: [EDUC] Github/Edu, JC Salmon - Collège de Cluses, 16/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 16/04/2018
- Re: [EDUC] Github/Edu, JC Salmon - Collège de Cluses, 16/04/2018
- Re: [EDUC] Github/Edu, Cédric Frayssinet, 17/04/2018
- Re: [EDUC] Github/Edu, William, 17/04/2018
- Re: [EDUC] Github/Edu, Cédric Frayssinet, 17/04/2018
- Re: [EDUC] Github/Edu, Gérard Vidal, 16/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 15/04/2018
- Re: [EDUC] Github/Edu, Marc Ferraton, 15/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 14/04/2018
- Re: [EDUC] Github/Edu, Romain, 14/04/2018
- Re: [EDUC] Github/Edu, William Gambazza, 16/04/2018
Archives gérées par MHonArc 2.6.19+.