lilypond-user-fr
[Top][All Lists]
Advanced

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

Re: Sondage : Qui est utilise “git” en compl ément de sont travail d'écr


From: Remy CLAVERIE
Subject: Re: Sondage : Qui est utilise “git” en compl ément de sont travail d'écriture de partition
Date: Sun, 25 Nov 2012 12:47:03 +0100 (CET)

Bonjour à tous,

 

Je crois qu'il faudrait aussi un site qui réperttorie tous les projets GIT pour 1) ne pas avoir de projets redondants 2) permette à celui qui est intéressé de se joindre au GIT.

 

Merci

 

Rémy




> Message du 23/11/12 22:41
> De : "Bertrand Bordage"
> A : "Jean-Jacques Gerbaud"
> Copie à : "lilypond-user-fr"
> Objet : Re: Sondage : Qui est utilise “git” en complément de sont travail d'écriture de partition
>
> Le 23 novembre 2012 21:14, Jean-Jacques Gerbaud <address@hidden> a écrit :
>
Tu as l'air calé en Git et on t'invite à nous donner notre première leçon car j'avoue que je suis assez admiratif d'utiliser Git pour tous tes travaux personnels (Lilypond, LibreOffice, etc...) et je voudrais bien comprendre ta manière de travailler.
>
> Je suis allé là : > http://git-scm.com/book/fr/D%C3%A9marrage-rapide-Param%C3%A9trage-%C3%A0-la-premi%C3%A8re-utilisation-de-Git
>
> et ai fait les premières manips pour que Git soit installé sur ma machine.
>
> Mais ...maintenant ?
>

>
Maintenant il faut apprendre les quelques commandes de base.  Git ayant été paramétré, il faut maintenant créer un "dépôt".  C'est le nom donné au répertoire dont on va suivre les changements.
Pour créer un dépôt :
  1. Dans un terminal, se placer dans le répertoire où on souhaite créer avec la commande cd /repertoire/a/surveiller (évidemment, c'est uniquement si le répertoire existe déjà).
  2. Exécuter git init
Ensuite il faut comprendre le cycle de travail commun à tous les logiciels de gestion de version.  Voilà le principe :
  1. On modifie les fichiers qu'on souhaite en essayant d'éviter de faire trop de modifications à la fois (sans quoi la relecture est hardue).
  2. On regarde le "diff" qui indique tous les changements ayant été faits sur des fichiers.
  3. On sélectionne les changements qui vont constituer le "commit" de l'étape suivante (étape facultative si toutes les modifications sont à prendre en compte).
  4. On fait un "commit".  C'est un genre d'enregistrement de tous les changements effectués depuis le dernier commit auquel on ajoute un message compréhensible comme "Ajout de la partie de basse continue dans le concerto RV 123".
  5. Si on a un dépôt distant (une copie sur internet de ce dépôt quoi), on peut vouloir faire une synchronisation avec ce dépôt distant.
Si cette façon de travailler est indispensable pour un groupe de développeur ou un développeur isolé, elle n'en est pas moins très utile pour n'importe qui d'autre.  L'avantage n°1 c'est la disparition des syndromes :
  • "Ah zut, ça marchait avant, je ne sais pas ce que j'ai fait mais ça ne marche plus" et
    >
  • "Ah, ça marche.  Je fais une copie de ce fichier/répertoire avec la date pour être sûr de pouvoir la retrouver quand j'aurais changé des trucs"
  • "Bon, j'ai bloqué pendant quelques heures sur ce problème.  J'ai fait plein de changements mais ne sais plus trop où j'en suis.  Cela marche à peu près mais je ne suis pas sûr de savoir pourquoi."
Voilà typiquement la façon dont on se sert de git pour un projet LilyPond tout neuf :
  1. mkdir essai_lilypond
  2. cd essai_lilypond
  3. git init
  4. On créé un fichier essai.ly dans lequel on met un système d'une portée
  5. git add essai.ly (cette commande permet de dire à git : "commence à suivre ce fichier" sans quoi il l'ignore totalement ; il ignorera donc les fichiers compilés genre PDF et MIDI, à moins que vous ne les ajoutiez avec cette même commande ; ce qui est à éviter, on préfère toujours ne garder que la source)
  6. git commit -m "Début de l'essai de partition avec un système tapée."
  7. On tape le second système
  8. git diff (montre avec des + et - ce qui a changé depuis qu'on a fini de taper le premier système)
  9. git add essai.ly (ce fichier avait déjà été ajouté ; cette commande sert désormais à dire de prendre ce changement en compte pour le prochain commit)
  10. git commit -m "Second système saisi."
On aurait pu aussi sauter l'étape 9 et ajouter l'argument -a pour dire "on prend en compte tous les changements de fichiers ajoutés déjà une fois".
Bon, je n'explique pas encore comment utiliser un dépôt distant.  Je conçois que cela peut déjà être perturbant comme façon de travailler.  Mais je vous garantis que cela vaut son pesant d'or si vous arrivez à commencer à vous en servir !

>
Avec des commandes plus avancées vous pouvez faire plein de choses : annuler n'importe quel changement, même lointain, en une commande, travailler en parallèle sur plusieurs choses sans qu'elles interagissent, mettre des changements de côté et les reprendre plus tard, faire fusionner automatiquement plusieurs changements, etc.  Et bien sûr, un avantage majeur : pouvoir rendre tout son travail plus compréhensible par n'importe qui passant derrière.  C'est ainsi vous assurer que vous pourrez mourir n'importe quand : votre travail pourra être poursuivi par quelqu'un d'autre.

>
Bon, enfin vous l'aurez compris, c'est pas supra simple mais ça vaut l'coup.
A plus,
Bertrand



_______________________________________________
liste de diffusion lilypond-user-fr
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user-fr


reply via email to

[Prev in Thread] Current Thread [Next in Thread]