{"partition": "head_middle", "source_domain": "linuxfr.org", "digest": "sha1:QRMQOMX7D35RUI4ZC6JKQOODD6RTBMWH", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2016-26/000_00010.parquet"}
Jeudi du Libre de décembre à Lyon : Git, ou comment donner l’impression qu’on est un supercodeur ?
Posté par Grumpf (page perso) le 24/11/11 à 17:28. Édité par Davy Defaud, Missumlaut, Nÿco, Malicia et Xavier Claude. Modéré par Nÿco.
Comme tous les premiers jeudis du mois, l’ALDIL organise une conférence pour présenter un logiciel libre et son utilisation. L’idée est d’alterner entre des conférences pour le grand public et d’autres interventions beaucoup plus techniques.
Ce jeudi 1er décembre rentre clairement dans la seconde catégorie, puisqu’il vise directement les développeurs avec une question que beaucoup ont déjà dû se poser : « Comment utiliser efficacement Git ? »
Annonce sur le site de l’ALDIL
Site officiel de Git
Git sur Wikipédia
Description de Git sur le projet PLUME
Git sur le site de l’ENS
Git, gestionnaire de versions décentralisé pour développeurs efficaces
Lorsqu’on est codeur, on a rapidement besoin d’un contrôle des codes sources pour enregistrer régulièrement l’état d’un projet, permettant ainsi de revenir en arrière en cas d’erreur. On peut alors récupérer un différentiel entre deux versions, localiser dans le temps l’introduction d’un problème dans les codes sources et bien d’autres choses encore…
Quand on travaille dans des projets communautaires, à force de regarder des jeux de patches sur les listes de diffusion ou sur une plate‐forme de suivi de bogues, on a tendance à croire que les alpha hackers, qui sont des contributeurs réguliers, ne font jamais d’erreurs… Chaque patch donne l’air d’être un ajout bien localisé, correctement formaté, testé et prêt à être intégré.
Où sont donc passés les commits intempestifs ? Les commentaires du type « Fix build » ? Les messages de type « Oups ! Oubli de… » ?
Ce tutoriel rapide de l’utilisation de Git dans la vraie vie donnera quelques astuces pour vous permettre, vous aussi, de masquer vos failles, et de paraître le meilleur des codeurs.
Le conférencier
Dave Neary est un membre de l’ALDIL depuis 2002, l’année où il est arrivé à Lyon.
Consultant spécialisé dans la gestion de communautés autour des projets libres, il a un passé de développeur et de release manager de GIMP. Il a aussi été organisateur d’événements, dont le premier Libre Graphics Meeting en 2006 à Lyon, et est membre du conseil d’administration du projet GNOME.
Il a également été impliqué dans les projets OpenWengo (devenu QuteCom), Maemo et MeeGo.
La conférence aura lieu à la Maison Pour Tous - Salle des Rancy :
249 rue Vendôme, 69003 Lyon (Métro Saxe‐Gambetta).
La présentation débutera à 19 h 30.
(10 commentaires).
Comment utiliser efficacement Git ?
Posté par jeberger (page perso) le 24/11/11 à 19:49.
Réponse: installer Mercurial...
-->[] je suis déjà dehors.
"Comment utiliser efficacement Git ?"
Posté par romrom le 24/11/11 à 19:54.
Évalué à -1.
Comment ? Heu... bien tester et un peu de bon sens, non ? Enfin je parle du problème de "commits intempestifs" parce que pour le reste, quand je vois le manuel de git, je me dis toujours que je ne suis pas prêt d'en maitriser tous les rouages... (sérieux, qui utilise git bisect par exemple ?)
Re: "Comment utiliser efficacement Git ?"
sérieux, qui utilise git bisect par exemple ?
Bin je n'ai jamais utilisé vu que je n'utilise pas git, mais j'ai souvent utilisé hg bisect et déploré l'absence d'une commande équivalente sous svn (au point d'importer une ou deux fois des historiques svn dans Mercurial juste pour pouvoir utiliser hg bisect dessus...) C'est 'achement pratique pour comprendre d'où vient un problème qui n'existait pas avant (ou pour comprendre comment un problème a été corrigé dans un projet que tu ne suis qu'occasionnellement).
C'est vrai que c'est moins utile quand tu développes seul et que le projet est suffisamment petit pour que tu aies tout en tête, mais dès que le projet grossit et que le nombre de développeurs augmente, c'est quasi indispensable.
Posté par Turbo le 24/11/11 à 20:53.
Pour git bisect et bien j'ai déjà utilisé deux fois en 4 ans (pas beaucoup c'est vrai) mais si je n'avais pas et bien j'aurais probablement perdu pas mal de temps. Je pense que cet outil à une très grande valeur!
Posté par Brice Goglin le 24/11/11 à 21:52.
git bisect n'est vraiment pas un bon exemple quand on parle de maitriser les rouages de git, c'est vraiment facile d'en comprendre la "théorie" et d'en maitriser la pratique...
Posté par cosmocat le 24/11/11 à 23:21.
Un des mainteneur de linux (je crois que c'est Greg Kroah-Hartman) a indiqué dans une interview qu'il utilisait régulièrement cette fonctionalité. Et qu'elle lui était devenu indispensable au vu du temps gagné. Mais tu pourras aller lui expliquer que c'est un guignol...
Dans son livre "Linux kernel in a nutshell", il recommande d'utiliser cette fonctionnalité lorsqu'on remonte une régression pour trouver le commit fautif.
Car cette fonctionnalité permet :
- de trouver un commit fautif même sans être un développeur et comprendre le code (testeur, mainteneur,intégrateur,...)
- trouver un commit fautif, si on est un gros faignant (en tout cas gain de temps --d'autant plus si on peut fournir un script de test, dans ce cas, on peut faire autre chose en attendant--)
- trouver un commit fautif lorsqu'on a pas la moindre idée d'où le problème peut venir (et çà, ça arrive...)
Mais peut-être que celui qui n'a pas tester ne peut pas comprendre...
Pour moi, c'est une des fonctionnalité majeur de git.
Posté par Riendf le 24/11/11 à 23:27.
'Comment ? Heu... bien tester et un peu de bon sens, non'
Tu commits que quand tout est fini toi, au risque de perdre une semaine de boulot si ta machine plante?
Posté par djano le 01/12/11 à 00:42.
Tu commites 100+ fichiers d'un coup toi?
Je plains le pauvre gars qui doit faire ta revue de code.
Les commits réguliers et individuels sont le mieux pour pouvoir travailler vite et faire souvent du refactoring.
1 commit = 1 intention
'Les commits réguliers et individuels sont le mieux pour pouvoir travailler vite et faire souvent du refactoring.'
Heu oui c'est ce que je dis, sauf que des fois tu commits des trucs pas forcement tip top. Ne serait ce que par securite. Genre l'option sur laquelle tu es en train de travailler, qui n'influe pas le reste de la branche donc 'sans risque' de faire merder le boulot des autres.
Posté par gregR ☯ (page perso) le 25/11/11 à 08:25.
Sam Ruby ?http://intertwingly.net/blog/2011/11/24/Experience-with-Git
http://gregr.fr