On me demande de travailler avec GIT !?

Support Debian
#1

Bonjour,

Je suis en train de traduire le contenu d’un site et son gestionnaire me demande ceci :

Je veux bien mais … je ne connais absolument pas ce Git ni même comment je peu, par exemple, travailler sur mes traductions chez moi, hors ligne puis, une fois les traductions terminées, transférer le contenu vers son Git.

Comment pourrais bien faire pour satisfaire à cette demande ?
Est-ce qu’il est possible de travailler sur une “copie conforme” de ce Git, en lui ajoutant une “branche” française une fois que j’aurai terminé mes traductions ?

J’ai bien lu des tas de tutos mais les infos reçues me sont un peu difficiles à assimiler :blush:
Que me faut-il installer sur mon ordi pour pouvoir travailler sous Wheezy, tranquillement, chez moi, avant de tout transférer sur le Git de l’auteur principal ?

Merci de m’aider un peu dans cette aventure. Je ne veux ppas risquer d’abîmer le travail de l’auteur ni devoir renoncer à mon objectif.

À titre indicatif :

guy# uname -a && lsb_release -a
Linux MGD0714 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 7.8 (wheezy)
Release:	7.8
Codename:	wheezy
#2

Je conseillerais le mémento git de Raphaël Hertzog :
amazon.fr/M%C3%A9mento-Git-% … it+hertzog
(désolé pour le lien vers un cybermarchand particulier)

C’est un peu ardu, mais c’est bien fichu. En gros le principe est que tu crées un copie locale du dépôt distant. Tu fais tes manips sur les données du dépôt local avec le logiciel de ton choix (potentiellement sous gestion de version, étape par étape : ajout/suppression de fichier, changement de contenu). Quand tu as un ensemble cohérent, tu le soumets au dépôt distant.

Le tout repose sur des différences entre fichiers (comme la fonction diff). Chaque “commit” stocke les modifications apportées (ajout/suppression de fichiers, ajout/suppression/modification de lignes de texte…). Il est possible de travailler à plusieurs sur un ensemble de fichiers de la sorte, en automatisant la mise en commun du travail, en prévenant la résolution des conflits, en conservant une trace de l’historique et revenir à tout moment à un état donné du contenu du dépôt (du dossier archivé en qq sorte). C’est vraiment le pied avec les fichiers texte, c’est pourquoi on t’a demandé ça.

Dans les faits, tu travailles dans répertoire de ton système de fichier local. Dans ce répertoire se trouve un dossier .git qui contient toutes les infos du dépôt git local. Pas de configuration particulière, je n’ai jamais rien compris à svn, là tout roule tout seul et repose sur le système de fichier, diff et ssh.

Qq conseils :
– régulièrement suivre/synchroniser les modifications sur le dépôt git central, pour éviter les conflits
– faire de petites contributions petites mais régulières (ce qui permet aussi d’éviter les conflits, et surtout il est plus facile d’annuler une modification de qq lignes cohérentes, plutôt qu’un gros commit avec pleins de grosses modifs et avec des corrections de typo ici et là); de plus ce type de participation permet de bien commenter l’historique
– n’aie pas peur de casser quelque chose : on peut annuler un commit, c’est le principe de la gestion de version

Bon courage !

#3

Git est avant tout un système de gestion de version. Ça n’a pas de sens de l’utiliser sans faire de gestion de version.

En fait Git ne stocke pas les différences mais toutes les versions successives de chaque fichier suivi. Les diff sont générés dynamiquement. C’est plus efficace pour afficher les différences entre deux versions de juste calculer le diff entre les deux que d’appliquer toutes les modifications intermédiaires.

#4

@Pascal : ok, je ne savais que toutes les versions étaient stockées telles que… Voyant ce message sans réponse, j’ai essayé de faire dans la vulgarisation :mrgreen: .

Dans le cas de PapyOctet, il s’agit de traduction de contenu, avec plusieurs contributeurs. Dans ce contexte, git me semble être plus utilisé pour le merge facile de toutes les contributions, que pour la gestion de version hyper-granulaire sur le poste de travail. Dans un tel workflow, la tâche cohérente est une bonne pavasse de texte, il n’y a pas de tests de régression, de variable qui tue qui change tout le fonctionnement de l’algo.

@PapyOctet :
Souhaiterais-tu traduire plusieurs parties en même temps, et pouvoir passer basculer de l’une à l’autre en cas de lassitude, tout en conservant une cohérence des modifications ? Dans ce cas il faudrait regarder du côté des « branches » git.

J’ai plutôt l’impression que tu cherches à savoir dans un premier temps comment interagir avec le dépôt du projet pour y contribuer.

#5

Le fait d’utiliser Git t’évitera obligatoirement de faire des bétises irréversible. Git conservant toutes les versions qu’on lui transmet si tu fait une bourde il suffit de revenir en arrière.
Donc pas de soucis de ce coté.

Mais le fait que tu ai cette crainte me laisse penser que tu n’es pas habitué a utiliser ce genre d’outil. :think:

#6

Bonjour à tous les intervenants,

Merci pour ces quelques conseils.
En effet, je n’ai encore jamais abordé Git … ni même svn d’ailleurs.

Les traductions que je veux faire puis publier le seront, selon mes possibilités, faites par “sujet”. Je prends un texte déjà publié en anglais, le ramène chez moi puis en fais la traduction en français (en y intégrant les images contenues dans le texte anglais, bien entendu). Une fois le texte traduit, je le publie en un seul bloc avant de passer au texte suivant. C’est pour respecter l’arborescence des fichiers d’origine, bien entendu.
Je dois, en quelle que sorte, recréer l’arborescence d’origine (les textes en anglais) mais avec les titres en français puis y insérer mes traductions (en accord avec le propriétaire du site). Pour cela, je suppose, au vu des quelques infos que j’ai tenté d’assimiler :unamused: , créer une nouvelle “branche” dans laquelle je vais pouvoir créer cet arbre.
Je ne vais pas essayer de tout traduire puis de tout publier en un bloc. Ce sera trop long à publier (mon temps libre …) et donc je travaillerai fichier par fichier.

Comme le suggère bobo38, c’est bien cela : essayer d’interagir avec un dépôt déjà existant.

Pour infos : le lien que je donnais plus haut correspond au site que je veux traduire. Mais il n’est pas sous Git mais il est sous un autre système et son auteur va passer, dans les semaines qui viennent sous Git qu’il trouve plus “efficace” et plus “sécurisant”.

A+

P.S.
Merci pour le lien vers le mémento. Je passe commande.

#7

La gestion de version c’est un peu compliqué à expliquer/comprendre sans cas d’application précis. L’idéal serait qu’on te ponde un “workflow”, avec les commandes qui vont te servir, quitte à ne pas comprendre TOUT ce qu’il se passe (ignorer les branches, les revert, la notion d’index ), en se focalisant sur la tâche de traduction et les spécificités de ton activité.

git clone : cloner le projet (à faire une fois)
git pull : synchroniser les dernières modifs’ du dépôt de référence
git add : ajouter un nouveau fichier que tu aurais créé pour copier le dossier que tu traduis
git diff HEAD : voir les différences avec la dernière version du dépôt local
git commit -a (combinaison de “git stage” et “git commit”) : met à jour le dépôt local pour prendre en compte le dernier état
git push : soumettre l’état courant au dépôt de référence

Ou alors qu’on te trouve une cheatsheet kivabien :
git-tower.com/blog/git-cheat-sheet-detail/

As-tu déjà essayé la commande “git clone code.google.com/p/dibl.wiki/” du lien posté plus haut ? (à faire dans un répertoire vide pour voir ce qu’il se passe, après avoir installé git).
Connais-tu bien le responsable du dépôt ? auquel cas tu pourrais faire quelques tests pour te sentir en confiance.

Il y a toujours l’alternative “otherwise follow the browse link to get source files of the wiki pages.”

#8

Bonjour bobo38,

Un tout tout grand MERCI pour ces infos.

La commande que tu propose pour “cloner” le site a bien fonctionné. J’ai reçu un dossier que j’ai ouvert avec Gitk (la version graphique de Git qui a été installée sur ma machine.
Il va falloir que j’essaie de comprendre comment ça fonctionne, ce que ça représente, bref, apprendre Git :doh:

Je vais voir, essayer, tester tout ça sur un “dépôt d’essai” et continuer dans l’étude de ce système qui, à en lire toutes les discussion que j’ai pu trouver est vraiment très efficace.

Je vois également les liens et les conseils que tu veux bien me donner.
J’attends la livraison du mémento avec impatience pour me plonger dans ce projet.

Merci.

Édition : Une doc plutôt complète et en français.
J’ai trouvé une doc complète, en français ici.

#9

Pour ma part j’ai joué un peu avec git pour un peu de développement python « maison » il y a quelques mois. Je partais avec des bases de gestion de version (svn, cvs, perforce), donc j’ai pu m’en dépatouiller assez facilement. Le mémento de Raphaël Hertzog est une petite merveille, qui permet de partir facilement et de prendre connaissance des .

Si tu fais qq scripts bash (ou autres), tu peux essayer de modifier ça sous git en local sur ta machine. Il faudrait que je m’y colle pour mes fichiers de config .vimrc .bashrc.

=== Tuto maison ===
Poussé par la curiosité, je viens de te créer un petit tuto qui correspond à comment je vois ton travail de traduction (je peux me planter). Tout est en ligne de commande et tu peux faire l’exercice pas-à-pas. Tu as même un petit challenge à la fin :wink:

Dans ce tuto, tu crées 2 dépôts git : un dépôt d’origine, symbolisant le dépôt du projet, et un clone local qui sert de répertoire de travail pour la traduction. Toute la partie manipulation de texte est faite avec echo et sed, tu peux naturellement utiliser l’éditeur de texte de ton choix. Il est très important de lire les messages de git. Une fois le mémento sous les yeux, ça pourra paraître un poil plus simple.

Désolé pour la partie finale, j’ai fait comme j’ai pu pour traiter push.

– Créer une arborescence de fichiers texte

mkdir -p ~/tmp/orig/en cd ~/tmp/orig/en echo "toto_en" > a echo "titi_en" > b echo "tutu_en" > c cd ..
– Initialiser un dépôt git et le remplir avec le fichier a

git init git add en/a git commit
– Cloner dans un autre répertoire et constater le résultat

mkdir -p ~/tmp/test cd ~/tmp/test git clone ~/tmp/orig ls tree
– Ajouter les autres fichiers dans le dépôt orig

cd ~/tmp/orig/en git add * git commit
– Synchroniser le dépôt cloné

cd ~/tmp/test/orig git pull
– Modifier un fichier dans le dépôt d’origine et constater la différence par rapport au précédent état du dépôt

cd ~/tmp/orig/en echo "new_line" >> b cp c d echo "tyty_en" > c git diff
– « Commiter » les modifications (je ne parlerais que de “git commit -a”, il y a moyen de faire plus granulaire; mais ce n’est pas le sujet :wink:)

git commit -a

– Synchoniser le dernier état du dépôt d’origine

cd ~/tmp/test/orig/en head * git pull head *
(À noter que d n’a pas été pris en compte, puisqu’il faudrait faire un git add pour le mettre sous contrôle de version)
– Intégrer le fichier d et resynchroniser dans le répertoire de travail

cd ~/tmp/orig/en git add d git commit cd ~/tmp/test/orig/en git pull
– Commencer le travail de traduction

cd ~/tmp/test/orig cp -r en fr cd fr sed -i -e "s/_en/_fr/" * head *
– a, c et d sont (déjà :mrgreen: ) traduits, on va les ajouter pour versionnage.

git add a c d git commit

Après ça devient un poil plus compliqué… J’ai fait des essais de “git push”. J’ai dû créer et basculer sur une branche “moi” pour réussir le push vers le dépôt d’origine. Moi qui ne voulais pas parler de branch… :013

cd ~/tmp/test/orig git branch moi git checkout moi git commit git push moi

Comme la branche “moi” n’existe pas encore sur le dépôt d’origine il faut « pousser » ainsi :

git push --set-upstream origin moi

On peut regarder ce que ça donne sur le dépôt d’origine

cd ~/tmp/orig tree git checkout moi tree
La branche “moi” a été crée. En basculant sur cette branche, le mainteneur voit tes modifications sur le dépôt central, libre à lui de les intégrer. À ce stade tu as publié/partagé ton travail. Un petit email et tu laisses le gonze finir le taf. Bref il faut que vous vous mettiez d’accord sur comment échanger avec le type. Je n’ai pas trouvé moyen de ne pas utiliser branch et merge, il est peut-être possible de s’en passer selon la configuration du dépôt sur le web.

Maintenant on simule l’arrivée d’un nouveau fichier sur le contenu “english” du dépôt d’origine

cd ~/tmp/orig/en git checkout master echo "tete_en" > e git add e git commit

Retour sur le « répertoire de travail local »; il faut faire attention aux branches !!

cd ~/tmp/test/orig git branch git checkout master git pull tree
On a mis à jour la branche “master” (il est possible de faire du “git remote update”) : en/e est présent. Voyons ce qu’il se passe sur la branche “moi”

cd ~/tmp/test/orig git checkout moi tree
Pas de fichier en/e. Pas de soucis on va faire un merge de la branche “master” qui vient juste d’être synchronisée.

git merge master tree

Normalement, tu devrais à ce stade être capable de finaliser la traduction de en/b et de en/e et de les publier sur le dépôt d’origine.

#10

Waouw ! Voilà une réponse … qui a demandé bien du boulot :118
Je plonge !

Je me replonge là-dedans :think: illico-presto :mrgreen:

Merci pour toutes ces infos très précieuses.

Édition :
Pour ma part, j’ai également continu d’écumer le Net et j’ai trouvé ceci, en français canadien :stuck_out_tongue: (28 minutes) qui est une bonne approche (visuelle) des possibilités de la “facilité d’utilisation” de Git.
Ce tuto survole également les avantages de Git par rapport à quelques autres système de gestion de mises-à-jour de dépôt.

Une autre vidéo (2 hrs. 20 min !), toujours en français ici. Mais c’est moins compréhensible, le commentaire est enregistré en direct dans la salle de cours et le son n’est pas très bon. Sans préjuger du contenu de cette vidéo, les commentaires semblent “décousus”, par difficiles à comprendre. Les affichages sur l’écran de la salle de cours sont assez bien lisibles pour pouvoir être retranscrits.

A+

#11

Bonsoir,

Pour ce qui est de plonger … je coule !

J’ai installé Git puis cloné la partie du site que je dois traduire. J’ai un dossier DiBL.wiki qui contient 3 autres dossiers dont un appelé “english” et un autre appelé “francais”. C’est dans ce dernier que je vais placer mes traductions du contenu de “english”.

Dans le dossier “francais”, il y a 3 fichiers : “_Footer.md”, “_Introduction_en_Français.md” et “_Sidebar.md”. Dans un premier temps, je dois traduire ces fichiers.

Mais là, je coince !
En console, je fais un :

~/Mon Git Laceioli/DiBL.wiki/francais$ dir
_Footer.md  Introduction-en-Français.md  _Sidebar.md

Il y a bien les 3 fichiers à traduire.
Si je suis la doc pour pouvoir modifier un fichier plus tard, je dois ajouter les fichiers :

~/Mon Git Laceioli/DiBL.wiki/francais$ git add *.md
guy@MGD0714:~/Mon Git Laceioli/DiBL.wiki/francais$ git status
# On branch master
nothing to commit (working directory clean)

Et là … pas de fichier à commettre.
Pour pouvoir travailler de temps en temps sur ces fichiers, je crée une branche :

~/Mon Git Laceioli/DiBL.wiki/francais$ git checkout -b en_cours Switched to a new branch 'en_cours'
puis je vérifie si je suis bien sur cette branche :

~/Mon Git Laceioli/DiBL.wiki/francais$ git branch
* en_cours
  master

J’y suis.

Et là … je suis bloqué !
Je ne parviens pas à comprendre ce que je dois faire pour pouvoir travailler sur ces 3 fichiers situés dans “francais”.

Help !

#12

Je ne connais pas GIT mais je travaille sur son ancêtre SVN
Le principe est à mon avis le même
Au début avec GIT tu récupères les fichiers (ce que tu as fait)
Ensuite tu les modifies (Il me semble qu’un fichier récupéré n’a pas besoin d’être ajouté ADD, qui doit être réservé aux nouveaux fichiers que tu veux transmettre)
Une fois ton fichier modifié, tu fais COMMIT, qui modifiera le fichier présent sur le dépôt.

Je n’ai pas compris ta raison de créer une nouvelle branche ?

#13

Parce que c’est conseillé dans la doc quand on travaille par intermittence sur des fichiers et que ces “morceaux de modification” ne valent pas la peine d’être commités.
Cela permet également à d’autres de travailler sur ces fichiers en même temps sans que ce pose de problème particulier.
Ce qui pourrait être le cas ici puisque le site est open source et donc accessible (après validation par le propriétaire) à tout qui veut y collaborer.

Mais bon. C’est ce que j’ai cru comprendre.

#14

git add ajoute des fichiers non-versionnés pour versionnage. Comme dit debianhadic, j’ai l’impression d’après ce que tu dis que les fichiers du répertoire français sont déjà sous versionnage : ils ont été créés lors du clonage.

Du coup tu peux passer l’étape suivante… modification de fichiers texte pour les traduire en Français :041

À propos des branches…
…c’est un coup à se perdre, surtout si tu n’es pas encore à l’aise avec l’engin. Dans mon tuto plus haut j’ai eu besoin d’en créé une uniquement pour pouvoir faire un push vers le serveur git d’origine.

L’intérêt des branches est surtout pour faire d’implémentation expérimentale dans des programmes existants. Ça évite de pourrir le code, et permet de tout jeter si ça ne fonctionne pas. Ça aide également à grouper les commits de façon cohérente, pour une fonction particulière. Il est possible de conserver les modifications en cours sur la branche master avec git merge. Pour de la traduction, comme tu traduiras bloc par bloc, de façon cohérente, tu ne vas pas modifier telles variables ou telle fonction qui risque de te faire perdre la compatibilité ascendante.

(en tout cas chapeau de te lancer là-dedans :clap: , la gestion de version c’est pas de la tarte)

#15

Suite à mon « tuto » plus haut, il y a un moyen de savoir ce qui n’est pas sous “revision control” (je ne sais pas comment traduire cette expression anglaise). S’il y a des fichiers non-suivis, git status les liste (en te disant comment faire pour les inclure).

$ cd ~/tmp/test/orig $ git status Sur la branche moi Votre branche est en avance sur 'origin/moi' de 2 commits. (utilisez "git push" pour publier vos commits locaux) Fichiers non suivis: (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé) fr/b aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)
fr/b était une copie de en/b avec une ligne encore en Anglais, que je n’ai pas inclut au suivi de version.

Pour apprivoiser la bête, je te proposerais bien cette manip’ :

cd ~/Mon\ Git\ Laceioli/DiBL.wiki/francais git status touch toto git status cd .. git status rm francais/toto git status
L’idée est de créer un fichier vide nommé « toto » (avec touch) qq part dans ton dépôt et d’en voir l’impact sur la sortie de git status. La manip’ s’achève par la suppression du fichier ajouté pour revenir à l’état initial.

#16

Bonjour les amis,

Comme me le rappelle bobo38, les éléments qui sont déjà en “visionnage, en suivi” et qui n’ont pas encore subi de modif (depuis que j’ai cloné le site) n’ont pas à apparaître dans cette “recherche”.
J’avais “oublié”, pas capté que Git vérifie systématiquement (à chaque ouverture sur ma machine) si un fichier a tété modifié ou pas. S’il ne l’a pas été, il n’y a rien à indiquer dans les suivis des documents. Ce ne sera que lorsque j’aurai "trituré ledit fichier que Git verra le changement et “m’obligera” à enregistrer ces modifs dans l’historique de suivi du site.

Je replonge :smiling_imp:

Mes pauvres neurones :unamused: eux aussi sont triturés en tous sens et à 65 piges … on n’a plus la vivacité qu’on avait à 20 ans :119

Merci.

Édition 06:15

J’ai donc traduit les 3 fichiers qui se trouvaient dans le répertoire “francais” (voir plus haut dans la discussion) avec Gedit.
Cela terminé, j’ouvre la console et me rends dans le répertoire en question et fais un :

~/Mon Git Laceioli/DiBL.wiki/francais$ git init
Initialized empty Git repository in /home/guy/Mon Git Laceioli/DiBL.wiki/francais/.git/

Une fois Git activé dans le dossier en question, je vérifie l’état du contenu :

:~/Mon Git Laceioli/DiBL.wiki/francais$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	"Introduction-en-Franc\314\247ais.md"
#	"Introduction-en-Franc\314\247ais.md~"
#	_Footer.md
#	_Footer.md~
#	_Sidebar.md
#	_Sidebar.md~
nothing added to commit but untracked files present (use "git add" to track)

Git m’indique que 3 fichiers ont été modifiés (les fichiers .md).
Git m’indique qu’il n’y a rien d’ajouté pour être “commit” (remis) dans la gestion des historiques).
Git me dit qu’il a trouvé des fichiers “untracked” (non-suivis) dans le répertoire. Il me dit d’utiliser la commande “git add” pour qu’il puisse commencer à suivre leur évolution.
Git me montre également les fichiers temporaires (leur nom se termine par le signe ~) qu’a créé Gedit pendant mon travail d’édition. Je n’ai pas besoin de ces fichiers dans mon travail.
Je vais ensuite “ajouter” les 3 fichiers modifiés dans mon Git local (je travaille sur mon ordinateur personnel après avoir cloné le wiki).

:~/Mon Git Laceioli/DiBL.wiki/francais$ git add *.md
guy@MGD0714:~/Mon Git Laceioli/DiBL.wiki/francais$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#	new file:   "Introduction-en-Franc\314\247ais.md"
#	new file:   _Footer.md
#	new file:   _Sidebar.md
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	"Introduction-en-Franc\314\247ais.md~"
#	_Footer.md~
#	_Sidebar.md~

Git me montre maintenant qu’il a ajouté les 3 fichiers désirés dans la liste des fichiers dont il devra suivre l’évolution (new file : … en vert dans la console).
Git m’indique toujours qu’il reste les 3 fichiers temporaires créés par Gedit qui ne sont pas suivis.

À ce stade-ci de mon travail, j’ai 3 fichiers qui sont dans la zone “de transit” de Git (ils sont dans “stage”, un endroit où ils sont temporairement placés avant de voir leurs modifications validées.

Et pour vérifier visuellement cela, j’ai installé une application graphique complémentaire de Git : Gitk.
Si je tente de lancer Gitk depuis le dossier “francais”, je reçois un message d’erreur qui me dit que Gitk n’a pas trouvé de dossier à ouvrir. Pour corriger cela, je dois retourner un niveau plus haut dans l’arborescence des fichiers de traduction =>

:~/Mon Git Laceioli/DiBL.wiki/francais$ cd ..
guy@MGD0714:~/Mon Git Laceioli/DiBL.wiki$ gitk

Et quand je lance Gitk, j’obtiens une vue d’ensemble de toutes les modifs qui ont déjà été faites dans ce DiBL.wiki :
drive.google.com/file/d/0B1uwVu … sp=sharing
Je ne montre qu’une petite partie de la fenêtre de Gitk qui contient l’info qui confirme la prise en compte TEMPORAIRE des modifications que j’ai apportées aux fichiers : c’est la première ligne, tout en haut à gauche dans l’image, celle précédée d’un point rouge et qui dit :

Ouf ! Je pense que j’ai bien travaillé jusqu’ici. Je peux refermer Gitk et continuer mon travail.

Une dernière vérification de mon travail en cours avec :

~/Mon Git Laceioli/DiBL.wiki/francais$ git diff --staged
diff --git "a/Introduction-en-Franc\314\247ais.md" "b/Introduction-en-Franc\314\247ais.md"
new file mode 100644
index 0000000..777f0ef
--- /dev/null
+++ "b/Introduction-en-Franc\314\247ais.md"
@@ -0,0 +1,5 @@
+DiBL est un patchwork de sous-projets en relation avec "Diagrams for Bobbin Lace" (Diagrammes pour la dentelle aux fuseaux).
+
+Ce patchwork en une série d'applications indépendantes, d'extensions (plug-in), de fichiers de code informatique (scripts) des bribes de code informatique, pour 
+
+Ils peuvent évoluer en des unités plus importantes et plus intéressantes.
diff --git a/_Footer.md b/_Footer.md
new file mode 100644
index 0000000..6b83c5c
--- /dev/null
+++ b/_Footer.md
@@ -0,0 +1,2 @@
+![](https://raw.githubusercontent.com/wiki/jo-pol/DiBL/images/logo.png)
+Traduction française souhaitée : A patchwork de sous-projets en relation avec **Di**agrams for **B**obbin **L**ace (Diagrammes pour la dentelle aux fuseaux).
diff --git a/_Sidebar.md b/_Sidebar.md
new file mode 100644
index 0000000..e972eb6
--- /dev/null
+++ b/_Sidebar.md
@@ -0,0 +1,26 @@
+* [[Outils disponibles | AvailableTools]]
+  * Générateurs de fonds/réseaux hors-ligne
...
+  * Préliminaires [[Conception | https://cdn.rawgit.com/wiki/jo-pol/DiBL/BobbinLaceDiagramTemplates.pdf ]] thougths.
+  * Modèles de pavages [[comparés | ComparedWithBobbinwork ]] avec des travaux de dentelles aux fuseaux abandonnés.
(END)

Et là, toutes les modifs que j’ai faites sont montrées (en vert dans la fenêtre de la console).
(Pour facilité la lecture, j’ai remplacé dans l’affichage du résultat, une grande partie des modifs par … )
L’affichage de la console s’interrompt après l’affichage de quelques lignes de modifs. Pour voir la suite il suffit d’appuyer sur la touche du clavier “flèche vers le bas”. En fin d’affichage des modifs dans la console, un [END] est montré.
L’affichage en console affiche le texte comme il a été tapé dans l’éditeur mais sans tenir compte des saut à la ligne automatiques faits dans l’éditeur de texte. À cause de cela, il est probable que l’entièreté du texte modifié ne sera pas affiché dans la console. En élargissant la fenêtre de la console, on voit la suite du texte. Ça rassure !

Pour revenir à la ligne de commande dans la console : tapez simplement “q” (sans les guillemets) pour “quitter”.

Voilà où j’en suis pour le moment :laughing:
Ça avance … doucement mais sûrement :stuck_out_tongue:

J’ai une petite appréhension avec les caractères accentués français le “ç” dans le nom d’un des fichiers. Mais je verrai cela plus tard.

Qu’on me corrige si j’écris des bourdes :075 … oui, bon. Moins violent, tout de même. Merci

#17

Étapes suivantes dans mon étude de Git.

J’ai donc traduit mes 3 fichiers en français et je les ai ajoutés aux suivis effectués par Git.
De multiples manières, j’ai vérifié le déroulement des opérations ainsi que des modifications apportées dans les 3 fichiers.

Je suis satisfait de mon travail et je peux maintenant “valider” ces modifications. pour cela, je vais devoir “commettre” (remettre) les fichiers à leur place dans le dossier d’origine.

Quand on “commet” un fichier (ou des fichiers) en attente (staged), on doit obligatoirement introduire un bref “justificatif” qui nous rappellera (dans l’historique des évolutions des fichiers) ce qui a été fait à un moment précis de l’évolution de ces fichiers.
Je ne connais pas, je ne pratique pas l’éditeur pas défaut utilisé avec Linux. Je préfère utiliser, ici, un éditeur simple mais efficace : Gedit.
Git me le permet bien aimablement avec :

~/Mon Git Laceioli/DiBL.wiki/francais$ git config --global core.editor gedit

Je vérifie si c’est fait :

~/Mon Git Laceioli/DiBL.wiki/francais$ git config --list
user.email=guy.laceioli@gmail.com
user.name=Guy Laceioli
color.ui=auto
merge.tool=vimdiff
core.editor=gedit
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true

C’est fait : core.editor=gedit.

Maintenant je vais “commiter” (remettre) mes fichiers en leur appliquant le même justificatif.

:~/Mon Git Laceioli/DiBL.wiki/francais$ git commit

Et là, mon éditeur favori, Gedit, est ouvert et Git a déjà introduit une série d’infos; par exemple :


# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: LISEZMOI
# modified: benchmarks.rb

et le curseur clignote à la première ligne qui est vide.
C’est là que je vais introduire mon petit texte (max 80 à 100 caractères est conseillé). Une ligne d’explication trop longue = trop de modif appliquée au document traité, dit-on ! Il vaut bien mieux d’effectuer de nombreuses “petites” modifs et de “commiter” souvent pour obtenir des étapes intermédiaires nombreuses qui permettront une meilleure gestion des modifs dans le cas où il faudrait en annuler certaines.

Je tape le justificatif : "First french translation"
Ben oui, “on” a l’habitude de faire ces commentaires en anglais (on = les informaticiens ;-0 ) mais ce n’est bien entendu pas obligatoire.
Toutes les lignes du fichier dans l’éditeur et qui sont précédées du # sont des commentaires qui ne seront pas pris en compte. On peut les supprimer, en enlever une partie ou ajouter d’autres commentaires personnel (en français, peut-être) qui nous expliqueront ce que nous venons de réaliser comme changements. Il vaut donc mieux conserver les noms des fichiers modifiés mais ce n’est pas impératif.

Je sauvegarde le fichier justificatif et Git va “récupérer” ma phrase de justification que j’ai écrite.
Ensuite, Git “commet” mes fichiers en ajoutant, dans l’historique des modifications, la phrase de justification que j’ai écrite.
Il m’affiche ce qu’il vient de faire :

:~/Mon Git Laceioli/DiBL.wiki/francais$ git commit

(gedit:5841): Gtk-CRITICAL **: gtk_list_store_set_column_types: assertion `priv->columns_dirty == 0' failed
[master (root-commit) 2e2cd46] First french translation
 3 files changed, 33 insertions(+)
 create mode 100644 "Introduction-en-Franc\314\247ais.md"
 create mode 100644 _Footer.md
 create mode 100644 _Sidebar.md

Maintenant un petit contrôle pour m’assurer que les fichiers ont bien été remis (commit) et qu’ils ne sont plus dans la zone intermédiare, de transit (stage) :

:~/Mon Git Laceioli/DiBL.wiki/francais$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	"Introduction-en-Franc\314\247ais.md~"
#	_Footer.md~
#	_Sidebar.md~
nothing added to commit but untracked files present (use "git add" to track)

On voit que mes 3 fichiers ont bien “disparu” de la zone intermédiaire : ils n’apparaissent plus (les fichiers terminés par “.md~” sont des fichiers temporaires créés par Gedit).

Git possède une autre outil qui nous permet de suivre les modifs apportées aux fichiers sur lesquels je travaille :

~/Mon Git Laceioli/DiBL.wiki/francais$ git log --summary
commit 2e2cd462b688f4c4adf78a45578f1664718af04e
Author: Guy Laceioli <guy.laceioli@gmail.com>
Date:   Tue Jan 20 08:53:22 2015 +0100

    First french translation

 create mode 100644 "Introduction-en-Franc\314\247ais.md"
 create mode 100644 _Footer.md
 create mode 100644 _Sidebar.md

On y voit le “justificatif” que j’ai composé dans Gedit ainsi que les noms de fichiers auxquels ce justificatif est appliqué dans l’historique des modifs.
Si j’ouvre GitK, j’obtiens ceci : drive.google.com/open?id=0B1uwV … authuser=0
On voit que, dans la branche “Master”, avec un justificatif “First french translation”, et, dans les deux fenêtres à droite, on voit l’auteur (avec son adresse de référence sur le site de destination et les date et heure de l’enregistrement (commit) des modifs.
Plus bas dans la fenêtre, on retrouve toutes les infos se rapportant à ce “commit” : les réfs de l’auteur, les noms des fichiers, et aussi le contenu des fichiers modifiés.

Il me reste maintenant à transférer ces modifications sur le site web distant pour que le titulaire du site puisse valider à son tour mes modifs et les afficher sur le site.

#18

C’est bien que ça avance… L’étape de prise en main en local a l’air d’être bien engagée :038 . Je suis curieux de connaître la suite : la propagation vers le serveur git du projet.

Une petite remarque toutefois :

[quote=“Papy Octet”]

~/Mon Git Laceioli/DiBL.wiki/francais$ git init Initialized empty Git repository in /home/guy/Mon Git Laceioli/DiBL.wiki/francais/.git/ [/quote]
J’ai l’impression que tu as créé un dépôt git vide à l’intérieur du dépôt git que tu avais cloné au préalable :

J'ai installé Git puis cloné la partie du site que je dois traduire. J'ai un dossier DiBL.wiki qui contient 3 autres dossiers dont un appelé "english" et un autre appelé "francais". C'est dans ce dernier que je vais placer mes traductions du contenu de "english".
#19

[quote=“bobo38”]C’est bien que ça avance… L’étape de prise en main en local a l’air d’être bien engagée :038 . Je suis curieux de connaître la suite : la propagation vers le serveur git du projet.
[/quote]

Hi hi. Moi aussi :laughing:

[quote]
Une petite remarque toutefois :
J’ai l’impression que tu as créé un dépôt git vide à l’intérieur du dépôt git que tu avais cloné au préalable :

J'ai installé Git puis cloné la partie du site que je dois traduire. J'ai un dossier DiBL.wiki qui contient 3 autres dossiers dont un appelé "english" et un autre appelé "francais". C'est dans ce dernier que je vais placer mes traductions du contenu de "english".

Parce que je n’arrivais pas à atteindre le contenu du dossier “francais” depuis le niveau supérieur “/DiBL.wiki/”.
Mais le .git dans “francais” n’est plus vide maintenant :083

#20

[strike]Je me pose une autre question :
J’ai vu quelque part - mais je n’arrive plus à retrouver la source - qu’il était possible de travailler sur son ordi sur un clone d’un site, ce que j’ai bien essayé ci-dessus et qu’il était possible de créer une copie de sauvegarde de notre travail sur un autre support (disque dur externe, par exemple).

Je continue à rechercher cette info mais si vous avez une réponse … je suis preneur.[/strike]

Merci.

Édition :

J’AI ENFIN COMPRIS :118 :041

Il y a des habitudes vraiment tenaces mais … il y a aussi un manque d’informations de la part des auteurs de ces nombreux tutos ! Alors que tous les tutos, la plupart bien faits se concentrent sur les commandes de Git, aucun de ceux que j’ai visités n’apportent LA précision indispensable pour comprendre le logiciel. Et cela, j’en suis certain, rebute une bonne partie des utilisateurs.

On y voit une collection impressionnante d’informations sur ce que peut faire Git mais jamais rien sur ce qu’il NE FAIT PAS !

Je m’explique.

Cela fais 3 ou 4 jours que je bataille avec Git et que je répète les tutos avec un exemple réel et concret de ce que je dois faire : traduire le contenu d’un site Web. Comme je l’indique dans cette série de messages, et après quelques … “pieds pris dans le tapis” :013 , je parviens à mes fins tout doucement.

Qu’est-ce que je reproche aux tutos (bien faits) ?
Bien peu de choses, en effet.

On sait ce que Git fait mais l’attention n’est pas attirée sur ce qu’il n’est pas :snooty:

Je lis, dans les tutos : “vous modifiez un tel fichier …”, les modifications que vous apportez à vos fichiers …" faites avec votre traitement de texte préféré, votre logiciel de traitement d’image préféré, …
C’est bien mais … je n’ai pas “capté” quelque chose qui m’empêche d’avancer promptement dans l’utilisation de Git.

Et puis, au gré de mes nombreux essais et des remarques de amis qui sont intervenus dans cette discussion, mes (vieux) neurones ont commencé à s’organiser et à me faire comprendre Git. Enfin !

Git, c’est quoi ?
Il est écrit partout que ce logiciel peut suivre toutes les modifications que vous (et d’autres personnes qui y ont été autorisées) allez apporter au contenu d’un répertoire.
Un répertoire, c’est un terme qui est pris, dans le cas de Git, au sens le plus large possible. Cela peut être un répertoire (un dossier) contenu sur votre propre ordinateur, un simple dossier contenant une série de fichiers que vous êtes amenés à modifier souvent, mais également, et c’est son but premier, le contenu d’un site Web, d’un wiki (une “encyclopédie” interactive), voir d’une archive quelconque (images, textes, vidéos, … ou même d’un disque dur tout entier !
Et quand on a compris cela c’est déjà un bon pas de réalisé.

La seconde chose importante qui est bien expliquée, c’est qu’on peut, via Git, travailler chez soi, sur son ordi personnel, pour apporter des modifications sur le contenu d’un site Web (avec les autorisations nécessaires de la part de son propriétaire, bien entendu) que Git a copié sur notre propre ordi personnel puis, quand on est satisfait, on peut “envoyer” toutes les modifs que nous avons apportées vers le site. Le propriétaire du site pourra alors, selon ses besoins, la pertinence qu’il estime valable de vos modifications, accepter ou refuser ces modifs.

L’info suivante : quoi que vous fassiez sur votre ordi perso, sur les pages Web (et leur contenu) que vous avez copiées (clonées), aucune des modifs faites sur la copie (le clone) du site se trouvant sur votre ordi perso et que vous transférez (push) vers ces pages web ne sera appliqué sans l’accord de son propriétaire !
Mais, et c’est ce qui fait la force de Git, chaque modification apportée à ces contenus que vous avez clonés sur votre ordi perso et que vous avez enregistrées (sur votre ordi) étape par étape de modification, sera également enregistrée sur le site auquel vous participez. VOUS NE POUVEZ PAS DÉTRUIRE, ABÎMER LE CONTENU DU SITE SANS L’ACCORD DE SON PROPRIÉTAIRE. Vous proposez, vous envoyez, le proprio accepte ou non.
Mieux encore, si, plus tard, une de vos étapes de modification ne vous convient plus, vous pourrez, grâce aux enregistrements des étapes de modification intermédiaires que vous avez enregistrées puis transmises, aller supprimer celle qui ne vous convient plus sans être obligé de recommencer tout le travail de correction.

Et après ? Qu’est-ce qui manque aux tutos ?
Ce que Git NE FAIT PAS !
Il peut gérer votre travail sur le contenu d’un répertoire. Oui et non !
Ce que Git fait, mais il le fait très bien et avec une somme de sécurités et de protection de votre travail, c’est vérifier systématiquement si le contenu d’un répertoire a été modifié par vous.
Vous avez, par exemple, un fichier de texte sur lequel vous travaillez et dans lequel vous apportez de légères (ou moins légères) modifications au gré du temps et de vos envies. Vous travaillez également sur un projet d’affiche pour la soirée pyjama de votre fils. Mais pour parvenir au résultat final accepté par l’utilisateur de votre travail, vous devrez vous devrez lui proposer des stades intermédiaires de votre travail, stades intermédiaires que vous ne voulez pas perdre, jusqu’à ce que le projet soit enfin accepté. Et même à ce moment, vous n’êtes pas certain que le “client” ne changera pas encore d’avis à la dernière minute; d’où la nécessité d’enregistrer tous ces stades intermédiaires (que Git fait très très bien !)…

Et bien Git ne va pas s’occuper de ce que vous faites dans ce fichier. Il ne corrigera pas les fautes d’orthographe, par exemple. Il va simple (et puissamment) vérifier s’il y a eu une modification apportée dans le répertoire (au sens le plus large du terme) puis il va repérer le fichier qui a été modifié. MAIS GIT NE MODIFIE AUCUN FICHIER. Chaque fichier se voit attribuer une “phrase de contrôle” qui correspond à l’état, au contenu du fichier à un instant donné. Dès que vous allez modifier ce fichier puis l’enregistrer (avec le logiciel correspondant : Writer, Gedit, Gimp, Inkscape, … tout logiciel capable de générer un fichier), Git va recalculer “la phrase de contrôle” et il la compare avec la dernière qu’il avait calculée avant votre intervention. Si les phrases sont différentes, quand vous enregistrerez, DANS GIT, le fait que le fichier a été modifié, Git va (et pour faire simple) enregistrer vos modifications (étape intermédiaire) et attribuer une nouvelle “phrase de contrôle” au dernier enregistrement du fichier sur lequel vous travailliez.
Dans la popote interne à Git, les tutos expliquent bien ce qu’il s’y passe et comment Git réalise ces sauvegardes.

Ce qui m’a rebuté dans mon approche de l’utilisation de Git, c’est que je restais obnubilé par “les modifications apportées au contenu du répertoire”. Je gardais à l’esprit, mais ne parvenais pas à comprendre, “modification”, “fichier” (dossier, répertoire), étapes intermédiaires MAIS EN ESSAYANT VAINEMENT DE COMPRENDRE COMMENT GIT PEUT MODIFIER CES CONTENUS.
GIT NE MODIFIE AUCUN CONTENU DE FICHIER ! Ce sont les logiciels avec lesquels ils sont conçus que ces fichiers sont modifiés.

Git fait des “photos”, des instantanés de votre travail en cours d’évolution, en fonction de ce que vous lui demanderez d’enregistrer, bien entendu. Si vous travaillez à 10 reprises dans un fichier mais que vous ne dites pas à Git d’enregistrer vos étapes … il ne le fera pas. Mais quand vous ouvrirez Git la prochaine fois, il pourra vous signaler que tel ou tel fichier a été modifié mais que vous ne lui avez pas demandé d’en prendre note. À vous, ensuite, de satisfaire Git et d’y enregistrer vos étapes de travail.
Git peut surveiller l’évolution de vos travaux en cours - à votre demande, bien entendu - transmettre ces modification à qui de droit, permettre une gestion très pointue de l’historique de vos travaux de modifications apportées dans un répertoire donné (voir les tutos appropriés). Il peut vous faciliter le travail si vous deviez, par exemple, annuler une partie des modifications que vous avez apportées dans un répertoire (et son contenu), par exemple, pour autant que vous l’alimentiez correctement.
Mais ce n’est pas lui qui va modifier le contenu d’un fichier, l’organisation d’un répertoire, d’un site Web, le contenu d’un wiki. Pour cela, il vous faut passer par l’emploi des logiciels appropriés !

Écrit comme ça, c’est normal. Mais … quand j’ai abordé Git … difficilement, je voulais absolument comprendre comment je pouvais modifier un fichier avec Git ! Et cette idée FAUSSE me cachait la vraie force de Git !

Cette erreur d’approche du logiciel m’a fait commettre une autre erreur d’appréciation : j’ai un répertoire (le site Web dont j’ai cloné le contenu pour le modifier - traduction de textes). Comme tout répertoire, j’ai des sous-dossiers dont certains contiennent des fichiers, ceux-là même que l’on m’a demandé de traduire et de corriger.
Dans Git, je voulais absolument me rendre dans le sous-dossier dans lequel se trouve le texte que je dois modifier pour y enregistrer les modifications que j’apporterai au fichier en question. => ERREUR ET INUTILE !
Git surveille le répertoire tout entier et donc, il suffit de rester à la racine de ce répertoire pour pouvoir enregistrer TOUTES VOS MODIFICATIONS apportées par vous à son contenu. Et même si vous travaillez dans un sous-dossier de 10° niveau, Git verra qu’un élément a été modifié !

Maintenant que j’ai compris cela, je vais corriger mes premières erreurs et recommencer le travail que je viens de réaliser tout au long de ces messages DANS GIT mais … je resterai à la racine du répertoire dans lequel je vais travailler et créerai le .git à cet endroit et non pas, comme je l’ai (si mal) fait précédemment.

J’espère que ces explications pourront servir à d’autre éventuels amateurs pour l’utilisation de Git et qu’il vous évitera de commettre les mêmes erreurs de débutant que moi :pray: