Discussion :

[Rikles]

Bonjour,
Je viens de publier un Tutoriel sur Git : Git - Démarrage rapide sous Linux

Vous le trouverez ici : http://loic-guibert.developpez.com/t...t/get-started/

Ce tutoriel est destiné aussi bien au développeur solitaire qui désire bénéficier rapidement d'un système de gestion de versions simple et efficace,
qu'à une équipe voulant mettre en place rapidement un système de gestion de versions collaboratif.

Ce tutoriel est accompagné d'une Visual cheat-sheet.

Vous pouvez utiliser cette discussion pour partager vos commentaires.

Loïc

[frfancha]

Merci de partager ce travail.

Attention à ce point:

A commit is a kind of "picture" of the working directory (a) => ok.
It saves the changes made since the commit previous (b) => pas ok!

Un commit dans GIT, contrairement justement à d'autres systèmes, ne sauve pas les changements depuis le commit précédent mais est bien une image complète de l'état au moment du commit (comme très bien dit dans (a) d'ailleurs).
En particulier le commit à lui seul suffit pour restaurer le systéme à l'instant T, et non pas une suite de commit qu'il faudrait appliquer chacun contenant les différences par rapport au précédent.

[Escapetiger]

(...)
Un commit dans GIT, contrairement justement à d'autres systèmes, ne sauve pas les changements depuis le commit précédent mais est bien une image complète de l'état au moment du commit (comme très bien dit dans (a) d'ailleurs).
En particulier le commit à lui seul suffit pour restaurer le systéme à l'instant T, et non pas une suite de commit qu'il faudrait appliquer chacun contenant les différences par rapport au précédent.

Tout à fait, c'est ce qui distingue fondamentalement Git de svn par exemple :

- Logiciel de gestion de versions décentralisé vs dépôt centralisé et unique

https://fr.wikipedia.org/wiki/Logici...on_de_versions
Logiciel de gestion de versions — Wikipédia

[Logan Mauzaize]

Merci de partager ce travail.

Attention à ce point:

A commit is a kind of "picture" of the working directory (a) => ok.
It saves the changes made since the commit previous (b) => pas ok!

Un commit dans GIT, contrairement justement à d'autres systèmes, ne sauve pas les changements depuis le commit précédent mais est bien une image complète de l'état au moment du commit (comme très bien dit dans (a) d'ailleurs).
En particulier le commit à lui seul suffit pour restaurer le systéme à l'instant T, et non pas une suite de commit qu'il faudrait appliquer chacun contenant les différences par rapport au précédent.

Pas tout à fait exact non plus Le commit ne contient qu'une arborescence de liens vers les objets de la base.

[Rikles]

Bonjour et merci pour vos retours.

Je suis bien conscient de comment fonctionne Git, les commits et le stockage des blobs.

Un commit est une sorte de « photo » du répertoire de travail. Il enregistre les modifications apportées depuis le commit précédent.

Ma deuxième phrase est sûrement mal tournée. Je voulais dire que sont enregistrées les "photos" des fichiers qui ont été modifiés, mais j'ai fait un raccourcis pour que ça soit plus lisible. Mais manifestement, cela peut être mal interprété et donc induire en erreur.
Deuxième point, ce tutoriel s'adresse aux débutants et je ne voulais pas entrer trop dans le détail du fonctionnement au risque de perdre voire de gaver le lecteur avant même d'entrer dans la pratique

Pour la gestion en mode "diff", Git le fait bel et bien, mais en à l'envers de ce qu'on trouve habituellement ! En effet, lors d'un "garbage collect" (git gc), Git va comprimer la base en regroupant les différentes "photos" d'un même fichier (ou se ressemblant s'il a été renommé) et va écrire un pack où l'on trouvera la "photo" complète de la dernière version du fichier et les "diff" à appliquer pour remonter dans les commits !

Pour résumer, je propose de modifier le tutoriel comme ceci :

Un commit est une sorte de « photo » du répertoire de travail. Il enregistre les fichiers modifiés depuis le commit précédent.

[Logan Mauzaize]

Deuxième point, ce tutoriel s'adresse aux débutants et je ne voulais pas entrer trop dans le détail du fonctionnement au risque de perdre voire de gaver le lecteur avant même d'entrer dans la pratique

Oups, je me rends compte que je n'avais pas donné mon avis sur la question ! Je plussoie de rester très simple, ceux qui veulent en apprendre plus pourront aller consulter un document comme Pro Git.

Pour ma part la notion de "changement" est quelque chose de très flou. Dire qu'un commit est une "photo" du répertoire de travail, cela me semble tout à fait compréhensible. Néanmoins j'aime bien la correction pour sa précision.

Et puis si on voulait chipoter c'est l'état de l'index (staging) qui est enregistré, et pas celui du répertoire de travail

[behess]

Etapes de lecture :

1) 1ère lecture : j'ai rien compris à l'article...

2) En fait, les flèches qui me perturbaient. Ce sont des pointeurs vers le commit précédent (vers l'arrière).

3) "master" en gris c'est en fait c'est "my" master : le gris correspond à mon repo local

4) le terme Checkout est source de confusion pour un habitué de SVN. Select aurait été préférable. on comprendrait plus facilement en venant d'un autre système...

5) finalement j'ai tout compris ! merci

[Logan Mauzaize]

En fait, les flèches qui me perturbaient. Ce sont des pointeurs vers le commit précédent (vers l'arrière).

Je ne connais pas la structure interne de Git mais c'est bien comme cela que sont présentés les commits avec des liens vers les parents et non le contraire.

"master" en gris c'est en fait c'est "my" master : le gris correspond à mon repo local

Une branche sans préfixe fait toujours implicitement référence au répo local tandis qu'une branche préfixée par un nom de "remote" (dépôt distant) fait implicitement référence aux états des branches de ce fameux dépôts. A noter que cet état des branches n'est pas temps réel et doit être mise à jour par des opérations "fetch".

le terme Checkout est source de confusion pour un habitué de SVN. Select aurait été préférable. on comprendrait plus facilement en venant d'un autre système...

L'idée d'un checkout c'est bien de mettre l'espace de travail dans un état donné par rapport à la gestion de configuration. Cela sous-entend un certains nombre de choses en SVN mais diffère de CVS, ClearCase, Git ou autres.
En plus c'est le vocabulaire Git ; ce serait encore plus perturbant de ne pas donner les bons termes.

[Ithildine]

Très bon guide sur Git, merci pour ton travail !

[Rikles]

Merci à tous pour vos retours. C'est motivant

[Rikles]

Bonjour,
Je viens de mettre à jour le tutoriel.

• J'ai appliqué la modification en discussion sur la définition d'un commit.
• J'ai apporté quelques ajustements dans le style.

[Invité]

Coucou et merci pour le tutoriel, ça fait un certain temps que je veux le digérer, mais, une partie du tutoriel me posait problème.

Pour les " débutants " il faudrait préciser que, depuis GNU/Linux, par défaut, les paquets openssh et openssh-client " devraient " être bien configurés, par défaut. Il suffit donc d'ouvrir le port de la Box, je ne suis même pas sur que ce soit nécessaire.

J'ai rencontré un problème de mon côté, car, j'avais surprotégé hosts.deny avec ALL donc, pas d'accès SSH. J'ai autorisé 2 ip 127.0.01 et 127.0.1.1 dans hosts.allow.

Ensuite, je remonte mon mécontentement ( il faut bien que je critique un peu, non ? )

Pour un tutoriel sur git, c'est plutot perdre le noob que de créer l'utilisateur git, de parler d'un dossier var/git, comme je disais sur le tchat, ouf que le domain du pc ne se nomme pas git

Bon, tu me diras, vu le temps que tu as passé à rédiger le tutoriel, il fallait bien que moi aussi je perde mon temps, pour le comprendre Pas vrai ? C'est chose faite, j'ai pu avancer, ouf, et, j'ai pu comprendre que ton tutoriel fonctionne parfaitement, c'était donc juste mon ignorance qui m'a freiné dans la mise en place de mon propre dépôt, quand j'ai changé le nom d'utilisateur ....

Je te propose de changer le nom d'utilisateur créé, git, pour un autre utilisateur, comme par exemple, utilisateurgit ou usergit, ou, monutilisateur ... mais, surtout, ne pas nommer l'utilisateur " git ".

J'ai repris ton tutoriel, sur mon wiki, en partie, pour apprendre, et, pratiquer, j'espère que ce n'est pas un problème (?).

Tu peux donc observer ce que j'ai modifié, et, adapter ton document d'origine : https://www.visionduweb.eu/wiki/inde...4t_Git_distant

J'ai également eu cette erreur :

Ne pas utiliser un nom d'utilisateur avec des majuscules

sudo adduser --no-create-home --home /var/git --shell /bin/bash Zer00CooL
adduser : veuillez entrer un nom d'utilisateur identique à l'expression régulière configurée
via la variable de configuration NAME_REGEX[_SYSTEM]. Utiliser l'option « --force-badname »
pour assouplir cette vérification ou reconfigurer NAME_REGEX.

Je n'ai pas voulu " --force -badname " ne sachant pas ce que cela ferait.

J'ai tenté, au filing, de créer mon utilisateur en minuscule, et, ça a fonctionné.

Savez vous me dire ce qu'il en est, si on " --force -badname " ?

Merci en tout cas, pour ton tutoriel, que je vais finir, cette nuit, ou, demain.

Merci également à l'équipe de rédaction de développez, qui m'a renvoyé vers cette page de discussion, pour me permettre de critiquer, cet horrible utilisateur " git:git " qui m'a perdu un bon moment quand moi, j'avais créé mon propre utilisateur " zer00cool:zer00cool" ... et, que je n'arrivais pas à initialiser le dépôt ... que je pestais contre le rédacteur .... pensant que je m'étais trompé, car, git était présent partout .... alors que, " simplement " c'était mon hosts.deny qui me bloquait, du fait qu'il était sur ALL, et, que je n'avais pas ajouté mes 2 ip locales dans hosts.allow, pour autoriser sshd.

Ici, pour hosts.deny et hosts.allow :
https://www.visionduweb.eu/wiki/inde..._et_hosts.deny

Pour ceux qui cherchent encore à configurer SSH, je suis entrain d'avancer sur mon tuto SSH, le début du tutoriel est rédigé et fonctionnel, pour gérer l'utilisateur zer00cool qui utilisera Git, sur le principe du tutoriel git.
https://www.visionduweb.eu/wiki/inde..._Git_zer00cool