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