Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2021-05-21T10:15:50+02:00Les derniers messages parus sur le forum de Zeste de Savoir.Comprendre Git, message #2344312021-05-21T10:15:50+02:00entwanne/@entwannehttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p234431<p>Salut,</p>
<p>J’ai fait le tour du tutoriel que j’ai trouvé pas mal, en plus c’est écrit par deux Pikachu !<br>
Dans la suite du message je reporte les différentes remarques que j’ai pu me faire selon les chapitres.
J’ai aussi relevé des petites fautes d’orthographe dont je fournis une liste par chapitre.</p>
<h3 id="installation-et-initialisation-de-votre-premier-dépôt">Installation et initialisation de votre premier dépôt<a aria-hidden="true" href="#installation-et-initialisation-de-votre-premier-dépôt"><span class="icon icon-link"></span></a></h3>
<p>Au long du tutoriel on comprend que git va permettre de travailler à plusieurs, mais comment concrètement ? Quel est le but ?
Qu’est-ce qui va faire qu’il sera plus facile de travailler à plusieurs sans se marcher dessus ?</p>
<p>Aussi est-ce que vous pourriez présenter les pré-requis nécessaires pour suivre le cours ? Je pense notamment au shell Linux.</p>
<h4 id="historique">Historique<a aria-hidden="true" href="#historique"><span class="icon icon-link"></span></a></h4>
<p>Je trouve la phrase sur Linux assez ambiguë (« Si vous vous intéressez à Git, vous connaissez surement Linux. Son développement est assuré par toute une équipe, et n’importe qui peut proposer des patchs. »).
Après l’avoir lue je n’ai pas compris que vous parliez du code de Linux et pas de celui de git.</p>
<p>Peut-être qu’il serait aussi préférable d’utiliser un terme plus générique que « mailing list » qui ne sera pas forcément compris de tout le monde.</p>
<h4 id="configurer-git">Configurer git<a aria-hidden="true" href="#configurer-git"><span class="icon icon-link"></span></a></h4>
<p>Je n’ai pas trouvé très logique de faire configurer le nom / email avant même de créer un premier dépôt ou un premier commit, ça a l’air de sortir de nulle part.<br>
À ce moment-là la configuration est globale, mais il ne serait de toute façon pas possible de faire une configuration locale car aucun dépôt n’existe.</p>
<h4 id="initialisation-de-votre-premier-dépôt">Initialisation de votre premier dépôt<a aria-hidden="true" href="#initialisation-de-votre-premier-dépôt"><span class="icon icon-link"></span></a></h4>
<p>Je ne suis pas très sûr que ce soit le lieu pour parler de vim, un autre éditeur ne pourrait pas être utilisé dans git bash ?
En plus, comme relevé par <a href="/membres/voir/Migwel/" rel="nofollow" class="ping ping-link">@<span class="ping-username">Migwel</span></a>, vous configurez nano comme éditeur par défaut juste avant.</p>
<p>Et je rejoins <a href="/membres/voir/sgble/" rel="nofollow" class="ping ping-link">@<span class="ping-username">sgble</span></a> sur le fait que ce serait cool de montrer <code>commit -m</code> tout de suite.</p>
<blockquote>
<p>Vous pouvez à tout moment voir l’état actuel de votre dépôt</p>
</blockquote>
<p>Qu’est-ce que l’état d’un dépôt ? Je pense que des explications seraient bienvenues.</p>
<h4 id="corrections-orthographiques">Corrections orthographiques<a aria-hidden="true" href="#corrections-orthographiques"><span class="icon icon-link"></span></a></h4>
<ul>
<li>« vous récupére<strong><del>r</del>z</strong> »</li>
<li>« et refaite<strong>s</strong> »</li>
<li>« ils ont décidé<strong><del>s</del></strong> »</li>
<li>« ils ont d’abord décidé<strong><del>s</del></strong> »</li>
<li>« BitKeeper fini<strong>t</strong> par »</li>
<li>« les même<strong>s</strong> principes »</li>
<li>« un des principaux système<strong>s</strong> »</li>
<li>« ouvrez […], puis tape<strong><del>r</del>z</strong> »</li>
<li>« deux commandes essentiel<strong>le</strong>s »</li>
<li>« seront donc bien évidemment différent<strong>s</strong> »</li>
</ul>
<h3 id="une-histoire-de-commit">Une histoire de commit<a aria-hidden="true" href="#une-histoire-de-commit"><span class="icon icon-link"></span></a></h3>
<p>Je trouve encore une fois que ça manque de concret.
On crée des commits qui ne contiennent pas grand chose, dans des fichiers un peu inutiles.
Mais ça ne répond pas vraiment à la question de fond : à quoi ça sert un commit ?</p>
<h4 id="un-commit">Un commit<a aria-hidden="true" href="#un-commit"><span class="icon icon-link"></span></a></h4>
<p>Vous nommez le premier commit <code>7a7c</code>.
C’est une notation valable mais est-ce que ce serait pas mieux d’utiliser les 8 premiers caractères du hash plutôt que seulement 4, pour rejoindre la notation généralement utilisée ?</p>
<h4 id="des-commits">Des commits<a aria-hidden="true" href="#des-commits"><span class="icon icon-link"></span></a></h4>
<p>Rien à redire si ce n’est que vivement l’arrivée des schémas !</p>
<h4 id="soyons-fainéants">Soyons fainéants<a aria-hidden="true" href="#soyons-fainéants"><span class="icon icon-link"></span></a></h4>
<p>J’aurais pensé que la section parlerait de <code>git diff --staged</code> pour bien illustrer les différentes zones.</p>
<h4 id="retrouvons-coco">Retrouvons Coco<a aria-hidden="true" href="#retrouvons-coco"><span class="icon icon-link"></span></a></h4>
<p>On voit apparaître un tag <code>Coco2</code> dans les logs git, c’est une erreur suite à un renommage ?</p>
<h4 id="corrections-orthographiques-1">Corrections orthographiques<a aria-hidden="true" href="#corrections-orthographiques-1"><span class="icon icon-link"></span></a></h4>
<ul>
<li>« toute<strong>s</strong> les modifications »</li>
<li>« ce que renvoi<strong><del>t</del>e</strong> »</li>
<li>« Chaque ligne précédé<strong>e</strong> »</li>
<li>« Le reste concerne le fichier concerné » → répétition</li>
<li>« les fichier<strong>s</strong> modifié<strong>s</strong> »</li>
<li>« les fichiers ajouté<strong>s</strong> (on dit aussi indexé<strong>s</strong>) »</li>
<li>« tou<strong><del>t</del>s</strong> les fichiers »</li>
<li>« les fichiers nouvellement créés (tel<strong>s</strong> que »</li>
<li>« ne faisant pas parti<strong><del>s</del>e</strong> »</li>
<li>« valide ses changement<strong>s</strong> » → et peut-être « ces »</li>
<li>« bien s<strong><del>u</del>û</strong>r »</li>
<li>« Les derniers commits sont affiché<strong>s</strong> »</li>
<li>« Il est effectivement plus utile<strong><del>s</del></strong> »</li>
<li>« quinze commits différent<strong>s</strong> »</li>
<li>« de notre dépôt<strong><del>s</del></strong> »</li>
<li>« sont très pratique<strong>s</strong> »</li>
</ul>
<h3 id="un-peu-de-jardinage">Un peu de jardinage<a aria-hidden="true" href="#un-peu-de-jardinage"><span class="icon icon-link"></span></a></h3>
<h4 id="une-nouvelle-amitié-qui-commence">Une nouvelle amitié qui commence<a aria-hidden="true" href="#une-nouvelle-amitié-qui-commence"><span class="icon icon-link"></span></a></h4>
<p>Les concepts de file et de bifurcation sont entremêlés dans l’introduction, on ne comprend pas nécessairement bien qu’un commit puisse apparaître dans deux files (branches) ni que des branches peuvent bifurquer puis se rejoindre (impossible avec des files).</p>
<p>Je pense aussi qu’il serait bon de présenter <code>git switch</code> comme alternative au <code>checkout</code>.</p>
<p>Les blocs de code sont un peu trop compacts et donc difficiles à suivre, peut-être faudrait-il les séparer en plusieurs blocs ?
Ça permettrait d’ajouter quelques commentaires au passage.</p>
<p>L’email n’est pas masqué dans tous les exemples.</p>
<p>Certaines images ont des problèmes de résolution pour les pancartes des branches ce qui les rend difficiles à lire.</p>
<h4 id="fuuuuuuu-sion">Fuuuuuuu-sion !<a aria-hidden="true" href="#fuuuuuuu-sion"><span class="icon icon-link"></span></a></h4>
<p>La section ne précise pas que deux branches peuvent modifier un même fichier sans que cela ne mène à des conflits, si les lignes impactées sont suffisamment distinctes pour que git s’y retrouve (et donc que c’est géré par la fusion automatique).</p>
<p>Le code sur le rebase est difficile à suivre, on voit les commandes sans comprendre ce que vous voulez faire, le rebasage n’est pas vraiment expliqué.
Ça mériterait peut-être une section à part, et je pense que les schémas gagneraient à être présentés avant le code pour expliciter ce qui va être fait. Et des schémas étape par étape permettrait de découper et aérer les blocs de code.</p>
<h4 id="le-super-héro-de-git">Le super-héro de Git<a aria-hidden="true" href="#le-super-héro-de-git"><span class="icon icon-link"></span></a></h4>
<p>On voit <code>^</code> et <code>~</code> utilisés mais pas vraiment expliqués, le seront-ils par la suite pour présenter leurs différentes possibilités ?</p>
<h4 id="corrections-orthographiques-2">Corrections orthographiques<a aria-hidden="true" href="#corrections-orthographiques-2"><span class="icon icon-link"></span></a></h4>
<ul>
<li>« Une branche <strong><del>à</del>a</strong> toujours un nom »</li>
<li>« les autre<strong>s</strong> utilisateurs du dépôt travaille<strong>nt</strong> »</li>
<li>« la fonctionnalité terminé<strong>e</strong> »</li>
<li>« Comment allons nous fusionner <strong><del>s</del>c</strong>es branches ? »</li>
</ul>
<h3 id="retour-vers-le-futur">Retour vers le futur<a aria-hidden="true" href="#retour-vers-le-futur"><span class="icon icon-link"></span></a></h3>
<h4 id="récupérer-un-fichier">Récupérer un fichier<a aria-hidden="true" href="#récupérer-un-fichier"><span class="icon icon-link"></span></a></h4>
<p>On ne comprend pas forcément le checkout, il n’est pas dit d’où le fichier est récupéré, et que les modifications non validées sont effacées.</p>
<h4 id="les-univers-parallèles">Les univers parallèles<a aria-hidden="true" href="#les-univers-parallèles"><span class="icon icon-link"></span></a></h4>
<p>Encore une fois difficile à suivre sans exemples concrets.
Est-ce qu’il ne pourrait pas y avoir un petit projet plus réaliste pour décrire les étapes ?</p>
<p>Par exemple vous pourriez présenter le git correspondant à la rédaction d’un contenu sur ZdS.</p>
<h4 id="remise-à-zéro">Remise à zéro<a aria-hidden="true" href="#remise-à-zéro"><span class="icon icon-link"></span></a></h4>
<p>Peut-être qu’il faudrait montrer des exemples d’utilisation où l’on revient sur des commits particuliers plutôt que sur HEAD.
Et présenter quelques cas d’usage où reset pourrait être utile.</p>
<h4 id="git-reflog">git reflog<a aria-hidden="true" href="#git-reflog"><span class="icon icon-link"></span></a></h4>
<p>Le cas d’usage est pertinent, peut-être qu’il faudrait juste remplacer <code>[COMMIT]</code> par l’id du commit dans l’exemple pour bien montrer ce qu’on souhaitait retrouver et où est écrite l’info dans le résultat de la commande.</p>
<h4 id="corrections-orthographiques-3">Corrections orthographiques<a aria-hidden="true" href="#corrections-orthographiques-3"><span class="icon icon-link"></span></a></h4>
<ul>
<li>« les modifications effectué<strong>es</strong> »</li>
<li>« n’importe quel<strong><del>le</del></strong> fichier »</li>
<li>« c’est quand m<strong><del>e</del>ê</strong>me fatig<strong><del>u</del></strong>ant de récupérer tou<strong><del>t</del></strong> ses fichiers » → et peut-être « ces » à la place de « ses »</li>
<li>« tou<strong><del>t</del>s</strong> les fichiers d’un commit »</li>
<li>« ce qui nous permet<strong><del>s</del></strong> »</li>
</ul>
<h3 id="lattaque-des-clones">L’attaque des clones<a aria-hidden="true" href="#lattaque-des-clones"><span class="icon icon-link"></span></a></h3>
<h4 id="échange-de-données">Échange de données<a aria-hidden="true" href="#échange-de-données"><span class="icon icon-link"></span></a></h4>
<p>Ça manque un peu d’explications autour de l’option <code>-a</code> de <code>git branch</code>.</p>
<h4 id="clonage">Clonage<a aria-hidden="true" href="#clonage"><span class="icon icon-link"></span></a></h4>
<p>Je trouve que le <code>git clone</code> arrive tard dans le processus.
Un dépôt d’exemple pourrait être fourni, à cloner dès le début du tutoriel : c’est plus comme ça que ça se passe en vrai que par un <code>git init</code>.</p>
<h4 id="corrections-orthographiques-4">Corrections orthographiques<a aria-hidden="true" href="#corrections-orthographiques-4"><span class="icon icon-link"></span></a></h4>
<ul>
<li>« vous le faite<strong>s</strong> »</li>
<li>« manière décentralisé<strong>e</strong> »</li>
<li>« l’authentification pouvant être facilité<strong>e</strong> »</li>
<li>« les dépôts distant<strong>s</strong> »</li>
<li>« l’envoi<strong><del>s</del>e</strong> »</li>
<li>« À note<strong><del>z</del>r</strong> »</li>
<li>« entre les branche<strong>s</strong> locales et distante<strong>s</strong> »</li>
<li>« une branche<strong><del>s</del></strong> »</li>
<li>« la copie local<strong>e</strong> »</li>
<li>« Il faut pense<strong><del>z</del>r</strong> »</li>
<li>« beaucoup de chose<strong>s</strong> »</li>
</ul>
<p>Voilà pour moi ! <img src="/static/smileys/svg/smile.svg" alt=":)" class="smiley"></p>Comprendre Git, message #2338792021-05-01T13:29:11+02:00Migwel/@Migwelhttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233879<h3 id="installation-et-initialisation-de-votre-premier-dépôt">Installation et initialisation de votre premier dépôt<a aria-hidden="true" href="#installation-et-initialisation-de-votre-premier-dépôt"><span class="icon icon-link"></span></a></h3>
<p>Dans la section Configurer Git, tu recommandes d’exécuter <code>$ git config --global core.editor nano</code> mais plus loin, quand tu parles de <code>git commit</code>, tu parles de vim. Si quelqu’un a suivi ton conseil, il ne verra pas vim mais nano.</p>
<h3 id="un-peu-de-jardinage">Un peu de jardinage<a aria-hidden="true" href="#un-peu-de-jardinage"><span class="icon icon-link"></span></a></h3>
<p>Sur le schéma "Commit casque bleu !", pourquoi y a-t-il un sparadrap sur le commit de la branche plutôt que sur celui de master?</p>
<p>Quand tu parles de git rebase, tu dis "Il n’y aura ainsi plus de conflit lors de la fusion de la branche secondaire dans la principale." mais directement après, tu montres un exemple de git rebase avec conflit. Ce n’est pas très clair ce que tu veux dire par là. Je pense que quand on parle de git rebase, il est important de préciser qu’il va modifier l’historique en "insérant" les commits au bon endroit dans la branche vers laquelle on rebase.</p>
<p>Quand tu parles de HEAD, ce serait bien de donner un peu plus d’explication que "HEAD fait une seul chose, il nous indique l’endroit où nous nous trouvons actuellement". Si je ne m’abuse, on peut voir HEAD comme un pointeur vers un commit et on peut faire bouger ce pointeur en utilisant git checkout. Ca peut aider à visualiser d’expliquer ça.
Tu peux aussi voir où est HEAD en utilisant git log. Je trouve toujours ça utile personnellement.</p>
<div class="hljs-code-div hljs-code-elixir"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span></div><pre><code class="hljs language-elixir">miguel<span class="hljs-variable">@laptop</span><span class="hljs-symbol">:/home/Miguel/Codes/test</span><span class="hljs-variable">$ </span>git log
commit b207db0eaeaa51cfdeb8634a1f880c84fac3d4b2 (HEAD -> master)
...
</code></pre></div>
<h3 id="retour-vers-le-futur">Retour vers le futur<a aria-hidden="true" href="#retour-vers-le-futur"><span class="icon icon-link"></span></a></h3>
<p>Concernant le detached HEAD, quand tu fais <code>git checkout vieuxCommit</code>, git te prévient déjà que tu es en detached head, pas besoin de faire de git status.</p>
<p>Il serait bon de mettre un gros warning autour de git reset car si il est utilisé sans y réfléchir convenablement, il peut avoir des effets désastreux.</p>
<h3 id="lattaque-des-clones">L’attaque des clones<a aria-hidden="true" href="#lattaque-des-clones"><span class="icon icon-link"></span></a></h3>
<p>Avant de proposer de faire un fetch du dépôt zds, je pense qu’il faudrait conseiller de créer un nouveau dossier sinon c’est perturbant (et pas du tout réaliste) d’avoir sa propre branch master qui n’a absolument rien à voir avec les branches qu’on vient de fetch.
La partie sur les dépôts distants est un peu rapide et pas très élaborée je trouve. Il faudrait expliquer la différence entre git fetch et git pull, le concept d’origin, parler de git pull —rebase, etc.</p>
<h3 id="divers">Divers<a aria-hidden="true" href="#divers"><span class="icon icon-link"></span></a></h3>
<p>Je pense que quelque part, il serait bon d’expliquer les différences majeures entre git et les autres gestionnaires de version comme SVN ou Mercurial.</p>
<p>En dehors de ça, j’aime beaucoup l’approche avec les exemples pratiques qui permettent de bien voir ce qu’il se passe ainsi que les schémas pour bien visualiser.</p>Comprendre Git, message #2331092021-04-08T21:18:18+02:00sgble/@sgblehttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233109<blockquote>
<p>Pour moi la cible est principalement ceux qui utilisent git sans comprendre. Je connais beaucoup trop de monde pour qui git est juste commit / push / pull ou une GUI et ne comprends pas ce qu’ils font (avec tous les problèmes que cela induit).</p>
<p>Je préfère donc partir de zéro et ne pas essayer de deviner ce que les lecteurs pourraient déjà connaitre. Ce qui peut effectivement le rendre accessible aux débutant complet, mais c’est tout aussi bien :D.</p>
</blockquote>
<p>Ok, ça se défend et dans ce cas je pense que le tutoriel a pour l’instant un rythme et un style qui reste cohérent avec ce niveau que tu vises. (j’avoue ça m’aurait semblé un peu abrupte si ça avait été pour le parfait débutant total)</p>
<blockquote>
<p>J’avoue que je n’utilise jamais switch et que je ne l’ai jamais vraiment vu utilisé non plus. Je laisserai checkout mais en ajoutant une note sur switch. Peu de personne connaissent vraiment switch et demander de l’aide sur checkout sera surement plus aisé actuellement.</p>
</blockquote>
<p>C’est vrai, c’est vraiment sur les toutes dernières versions de <code>git</code>, et même pas sûr que toutes les distributions l’incluent déjà <img src="/static/smileys/svg/smile.svg" alt=":)" class="smiley"></p>Comprendre Git, message #2331072021-04-08T19:59:34+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233107<figure><blockquote>
<p>Pour moi la cible est principalement ceux qui utilisent git sans comprendre. Je connais beaucoup trop de monde pour qui git est juste commit / push / pull ou une GUI et ne comprends pas ce qu’ils font (avec tous les problèmes que cela induit).</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233106">Gagaro</a></figcaption></figure>
<p><a href="https://zestedesavoir.com/billets/3520/git-la-gui-est-votre-amie/">Je pose ça là</a>.</p>
<p>Sinon je n’ai pas encore eu le temps de lire ton tuto, donc je n’ai pas encore d’avis dessus. Mais je ne peux qu’appuyer l’initiative.</p>Comprendre Git, message #2331062021-04-08T19:53:52+02:00Gagaro/@Gagarohttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233106<p>Merci pour les retours !</p>
<p>Pour moi la cible est principalement ceux qui utilisent git sans comprendre. Je connais beaucoup trop de monde pour qui git est juste commit / push / pull ou une GUI et ne comprends pas ce qu’ils font (avec tous les problèmes que cela induit).</p>
<p>Je préfère donc partir de zéro et ne pas essayer de deviner ce que les lecteurs pourraient déjà connaitre. Ce qui peut effectivement le rendre accessible aux débutant complet, mais c’est tout aussi bien :D.</p>
<blockquote>
<p>On peut peut-être privilégier git commit -m '[message]', ce qui évite l’ouverture d’un éditeur (surtout quand c’est Vim !), et donc ce qui évite de charger mentalement d’autant plus le lecteur qui n’est pas forcément déjà très à l’aise avec le terminal.</p>
</blockquote>
<p>Effectivement. Je vais quand même laisser le passage sur vim au cas où quelqu’un essayerai de taper <code>git commit</code> directement…</p>
<blockquote>
<p>Superbes illustrations <img src="/static/smileys/svg/heureux.svg" alt=":D" class="smiley"> </p>
</blockquote>
<p>C’est ma femme qu’il faut remercier pour cette partie <img src="/static/smileys/svg/rire.svg" alt=":lol:" class="smiley"> .</p>
<blockquote>
<p>Une remarque au passage : sur les nouvelles version de git, il est conseillé d’utiliser git switch plutôt que git checkout pour changer de branche ou en créer une nouvelle (comme avec checkout -b qui devient switch -c)</p>
</blockquote>
<p>J’avoue que je n’utilise jamais switch et que je ne l’ai jamais vraiment vu utilisé non plus.
Je laisserai checkout mais en ajoutant une note sur switch. Peu de personne connaissent vraiment switch et demander de l’aide sur checkout sera surement plus aisé actuellement.</p>
<p>À noter qu’il y a aussi <code>git restore</code> pour remplacer certaines fonctionnalités de <code>reset</code> / <code>checkout</code>. Mais je ne trouve pas que rajouter une commande de plus avec ses propres options soient vraiment pertinent pour une introduction à la compréhension de git.</p>Comprendre Git, message #2330852021-04-07T19:15:48+02:00ache/@achehttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233085<p>Je suis loin d’avoir tout lu mais c’est prometteur !</p>Comprendre Git, message #2330782021-04-07T16:59:18+02:00sgble/@sgblehttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233078<h4 id="choix-du-titre-et-structure-générale">Choix du titre et structure générale<a aria-hidden="true" href="#choix-du-titre-et-structure-générale"><span class="icon icon-link"></span></a></h4>
<p>Le choix du titre me fait penser directement à un contenu qui s’adresse à un public débutant-intermédiaire qui a déjà fait ses premiers pas avec l’outil, mais qui aimerait maintenant <em>comprendre</em> en détail ce qu’il fait et comment ça marche. Or, cela semble être un contenu adressé aux parfaits débutants qui n’ont même pas encore installé <code>git</code> si j’en crois les premières lignes.</p>
<p>D’un autre côté, je trouve que le titre correspond parfaitement dans la mesure où après avoir lu cette bêta, je me dis que le contenu peut très bien être utile à quelqu’un qui utilise déjà git en le « subissant » à copier ou en retenant les commandes, mais qui n’a jamais vraiment compris. Dans ce cas, on a sûrement une bonne base pour ce genre de débutants qui veut <em>comprendre</em> Git et arrêter de tâtonner dans l’obscurité avec.</p>
<h4 id="initialisation-de-votre-premier-dépôt">Initialisation de votre premier dépôt<a aria-hidden="true" href="#initialisation-de-votre-premier-dépôt"><span class="icon icon-link"></span></a></h4>
<p>On peut peut-être privilégier <code>git commit -m '[message]'</code>, ce qui évite l’ouverture d’un éditeur (surtout quand c’est Vim !), et donc ce qui évite de charger mentalement d’autant plus le lecteur qui n’est pas forcément déjà très à l’aise avec le terminal.</p>
<h4 id="commits">Commits<a aria-hidden="true" href="#commits"><span class="icon icon-link"></span></a></h4>
<p>Le tutoriel choisit une voie classique en présentant le commit comme pierre angulaire de Git. J’ai rien à redire là-dessus, et je trouve que le travail de vulgarisation là-dessus est bien parti (surtout avec les schémas attendus).</p>
<h4 id="un-peu-de-jardinage">Un peu de jardinage<a aria-hidden="true" href="#un-peu-de-jardinage"><span class="icon icon-link"></span></a></h4>
<p>Superbes illustrations <img src="/static/smileys/svg/heureux.svg" alt=":D" class="smiley"></p>
<p>Une remarque au passage : sur les nouvelles version de <code>git</code>, il est conseillé d’utiliser <code>git switch</code> plutôt que <code>git checkout</code> pour changer de branche ou en créer une nouvelle (comme avec <code>checkout -b</code> qui devient <code>switch -c</code>)</p>
<p>Étant donné que <code>checkout</code> a quand même tendance à faire <em>tout</em>, c’est peut-être une bonne chose d’introduire <code>swicth</code> pour limiter la charge mentale. Surtout que le chapitre d’après montre encore d’autres usages de <code>checkout</code>.</p>
<p>C’est tout pour moi, pour le moment <img src="/static/smileys/svg/clin.svg" alt=";)" class="smiley"></p>Comprendre Git, message #2330762021-04-07T16:08:05+02:00Gagaro/@Gagarohttps://zestedesavoir.com/forums/sujet/15228/comprendre-git/?page=1#p233076<p>Tout le monde se secoue ! <img src="/static/smileys/svg/heureux.svg" alt=":D" class="smiley"></p>
<p>J’ai commencé (lundi 02 mai 2016 à 18h43) la rédaction d’un tutoriel au doux nom
de « Comprendre Git » et j’ai pour objectif de proposer en validation
un texte aux petits oignons. Je fais donc appel à votre bonté sans
limites pour dénicher le moindre pépin, que ce soit à propos
du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à
l’adresse suivante :</p>
<div class="align-center"><p> <a href="https://zestedesavoir.com/contenus/beta/1293/comprendre-git/">À présent, c’est à vous !</a> </p></div>
<p>Merci !</p>Système de gestion de contenu versionné, message #1453962017-03-23T07:26:30+01:00Javier/@Javierhttps://zestedesavoir.com/forums/sujet/8275/systeme-de-gestion-de-contenu-versionne/?page=1#p145396<p>C’est sûrement pas ce que tu recherches exactement. Mais multó-édition + versionnage pour moi ça évoque aussi (en marge du wiki cf. ci-dessus) : un Gestionnaire Électronique de Documents (GED). Y’a des solutions open source. Ptetre même que y’a des solutions OSS qui reposent aussi sur des APIs ? Auquel cas t’u serais "presque". </p>
<p>Dans le pire des cas ça peut au moins t’inspirer. </p>Système de gestion de contenu versionné, message #1453272017-03-22T16:37:43+01:00Davidbrcz/@Davidbrczhttps://zestedesavoir.com/forums/sujet/8275/systeme-de-gestion-de-contenu-versionne/?page=1#p145327<p>Multi édition + versionnage, c’est le wiki qui me vient en tête, tu as déjà du filtrage (par catégorie ou par utilisateur), du versionnage, et des pages de commentaire pour chaque page de wiki. </p>
<p>Le soucis, c’est de passer ces 100 pages (papier ?) dans le wiki. L’idéal serait de rédiger le CdC dans le wiki même si je suppose qu’en pratique tu vas plus avoir (au mieux) un document word ou pdf. Il faudrait voir comment l’importer.</p>Système de gestion de contenu versionné, message #1453252017-03-22T16:16:43+01:00Abdelazer/@Abdelazerhttps://zestedesavoir.com/forums/sujet/8275/systeme-de-gestion-de-contenu-versionne/?page=1#p145325<p>Bonjour à tous,</p>
<p>Dans le cadre d’un projet universitaire, je dois travailler sur une problématique réelle d’une entreprise (avec laquelle je collabore) et développer une solution qui satisfasse ses besoins. Pour des raisons de confidentialité je ne peux malheureusement pas présenter certaines informations mais je vais essayer d’expliquer au mieux la problématique.</p>
<p>Assez basiquement, l’entreprise fournit une solution, disons mécanique, complexe et sur mesure à des clients. Ces derniers arrivent avec une cahier des charges précis (qui peut aller, disons, de 2 à 100 pages A4). Je suis mandaté par l’entreprise pour développer un système qui permette de gérer, tout au long du processus de fabrication, de validation, de chiffrage, etc, ce cahier des charges. Actuellement c’est une très grande feuille excel qui est envoyée aux différents départements, qui mettent dessus des commentaires et la renvoient à la direction qui procède à la fusion à la main (c’est donc méchamment le bordel) et ainsi de suite.</p>
<p>Ce que doit apporter mon système c’est :</p>
<ol>
<li>Pouvoir filtrer les informations selon des <em>tags</em> (au sens large, des groupes : par exemple des groupes d’utilisateur) ;</li>
<li>Pouvoir commenter chaque point du cahier des charges ;</li>
<li>Tout en ayant la possibilité de revoir ce document à un instant T (donc un document versionné).</li>
</ol>
<p>Actuellement, et sans y avoir réfléchit à fond, je partirai sur un document soit en <code>XML</code> soit sous la forme d’une arborescence de fichier (chaque points du cahier des charges est un fichier dans un dossier qui représente les sections) dans un format <code>XML</code> ou <code>JSON</code>, le tout embarqué dans un repo GIT. De là je pensais faire un programme (probablement en python) qui manipule le repo GIT et expose une API REST permettant de récupérer ou de modifier les données. La visualisation se ferait dans un client à part (c’est moins important pour le moment).</p>
<p>Je vais bien évidement procéder, avant de faire un choix, à un <abbr title="State of the art">SOA</abbr>. Mais j’aimerai beaucoup avoir votre avis sur ma première idée et sur d’autres propositions que vous pourriez avoir. Bien entendus je vais faire mes recherches à fond mais si vous connaissez une technologie qui pourraient être intéressantes, n’hésitez pas à m’en parler.</p>
<p>Une très bonne journée à vous tous <img alt=";)" src="/static/smileys/clin.png"></p>Participer à des projets open-sources avec Git et GitHub, message #1043012016-03-29T10:16:30+02:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p104301<p>Bonjour,</p>
<p>La bêta du contenu « Participer à des projets open-sources avec Git et GitHub » a été désactivée.</p>Participer à des projets open-sources avec Git et GitHub, message #1038252016-03-24T20:20:09+01:00adri1/@adri1https://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103825<p>Du coup, il n'est peut être pas utile de le laisser en validation, ça évitera qu'un valido commence à travailler sur la version courante et que tu modifies des trucs entre temps.</p>Participer à des projets open-sources avec Git et GitHub, message #1038232016-03-24T19:52:57+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103823<p>ouai, je vais le retravailler.</p>Participer à des projets open-sources avec Git et GitHub, message #1038202016-03-24T19:28:31+01:00adri1/@adri1https://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103820<p>Salut,</p>
<p>C'est un peu dommage de l'envoyer en validation avant même d'attendre des retours sur la bêta…</p>
<p>Je viens de lire le tuto, et j'avoue que mon avis n'a pas changé depuis la dernière fois. Le tuto manque de <em>relief</em> dans les informations. Ça part dans tous les sens sans mettre de contraste d'importance entre ce qui tient du tuyau et ce qui est vraiment essentiel de comprendre. Si j'essaye de me mettre à la place du débutant, je ne pense pas que j'arriverai au bout du cours en ayant une idée précise de ce qui vient de se passer, et de comment différents concepts proches (comme commit, push, et pull request) s'articulent les uns avec les autres.</p>Participer à des projets open-sources avec Git et GitHub, message #1037712016-03-24T14:00:28+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103771<p>Bonjour les agrumes !</p>
<p>La bêta a été mise à jour et décante sa pulpe
à l'adresse suivante :</p>
<div align="center">
<p><a href="http://zestedesavoir.com/contenus/beta/380/participer-a-des-projets-open-sources-avec-git-et-github/">Participer à des projets open-sources avec Git et GitHub</a> </p>
</div>
<p>Merci d'avance pour vos commentaires.</p>
<p>Pas mal de modifs réalisées :</p>
<ul>
<li>corrections diverses par situphen</li>
<li>ajout d'images pour montrer une vue plus graphique des actions à effectuer</li>
<li>reformulation de certaines phrase sur la manière de faire une pull/request ou d'y participer</li>
<li>ajout du cartouche zep-jesaisplusquoimaisdominusdevraitaimer</li>
</ul>
<p>Le tuto a été envoyé en validation mais je pense que le staff est quelque peu overbooké en ce moment.</p>Participer à des projets open-sources avec Git et GitHub, message #1036382016-03-23T13:43:31+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103638<p>Bonjour les agrumes !</p>
<p>La bêta a été mise à jour et décante sa pulpe
à l'adresse suivante :</p>
<div align="center">
<p><a href="http://zestedesavoir.com/contenus/beta/380/participer-a-des-projets-open-sources-avec-git-et-github/">Participer à des projets open-sources avec Git et GitHub</a> </p>
</div>
<p>Merci d'avance pour vos commentaires.</p>Participer à des projets open-sources avec Git et GitHub, message #1036362016-03-23T13:17:47+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103636<p>Oyez oyez les agrumes !</p>
<p>Je vous annonce avec plaisir la ré-ouverture de la bêta du contenu
« Participer à des projets open-sources avec Git et GitHub » ! Je vous souhaite une agréable lecture à l'adresse
suivante :</p>
<div align="center">
<p><a href="http://zestedesavoir.com/contenus/beta/380/participer-a-des-projets-open-sources-avec-git-et-github/">Je suis de retour !</a> </p>
</div>
<p>Merci pour votre participation.</p>
<p>J'ai fait pas mal de modifs pour rendre le tutoriel moins orienté ligne de commandes et pour faire un peu mieux comprendre le principe de git.</p>
<p>Je vais bientôt le proposer à la validation, une fois que j'aurai glissé un mot sur les templates de PR/Issue.</p>Participer à des projets open-sources avec Git et GitHub, message #1032822016-03-20T14:00:25+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103282<p>Bonjour,</p>
<p>La bêta du contenu « Participer à des projets open-sources avec Git et GitHub » a été désactivée.</p>
<p>J'ai désactivé la béta le temps de rentrer dans le contenu et d'y appliquer quelques modifications substentielles. Ca reviendra rapidement, ne vous inquiétez pas.</p>Participer à des projets open-sources avec Git et GitHub, message #1032802016-03-20T13:42:45+01:00Situphen/@Situphenhttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103280<p>C'est fait <img alt=";)" src="/static/smileys/clin.png"></p>Participer à des projets open-sources avec Git et GitHub, message #1032172016-03-19T20:20:14+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/2645/participer-a-des-projets-open-sources-avec-git-et-github/?page=2#p103217<p>ça te dirait de m'ajouter en coauteur que je vois ce que je peux y faire?</p>