Évidemment, mais d’expérience ce point pose moins de problème qu’une branche. J’ai rarement croisé des gens qui avaient du mal à comprendre ce qu’est un commit Git ; par contre, des gens qui sont persuadés que « Une branche c’est un historique linéaire de commits » (ou quelque chose d’approchant), c’est extrêmement fréquent.
Je pense qu'il est extrêmement fréquent de ne pas comprendre que les parents d'un commit fait parti de son identité et qu'un cherry-pick par exemple, c'est un nouveau commit qui n'a aucune relation avec sa copie d'origine au sens de l'arbre d'objet git.
Pour le reste, à partir du moment où tu en es à « capitaliser sur ta connaissance de ZSH », tu n’est probablement pas dans la cible du billet.
C'est un peu le problème. git n'a pas était conçu pour être un gestionnaire de version simple à poser dans toutes les mains, mais un outils qui ne fait pas de concession pour la performance et taillé pour un projet précis. mercurial (que je préfère à git) est déjà un peu plus fait pour le tout venant même si je ne suis pas convaincu qu'un DCVS soit la panacée en soit. La gestion de version par les outils de traitement de texte bien que triviaux sont déjà une gageure pour beaucoup et j'ai l'impression que les outils qui s'en sortent le mieux pour ça sont ceux qui sauvegardent tout le temps et te permettent de revenir dans le temps de manière uniquement temporel (ils ne répondent qu'à des demandes de la forme "montre moi mes fichiers il y a 3h").
Utiliser une GUI permet de mieux comprendre fonctionnellement Git, ce qu’il fait, pourquoi, et donc de l’utiliser efficacement – même si ça demande de sortir un autre outil comme la CLI pour arriver à cette fin.
Les meilleurs outils pour voir ce que fait git que j'ai pu voir était des outils d'apprentissage où tu a l'écran divisé en 2 et ou tu vois en temps réel (par un rafraichissement régulier d'une vue) ce qui se passe dans ton graphe au fur et à mesure que tu lance des commandes et où tu peux revenir en arrière de manière instantanée et fiable via un bouton "back".
Après ça vient peut être d'avoir un esprit bottom-up ou top-down, mais ça me demande un effort considérable pour aller plus loin que ce qu'une GUI me propose.
[^] # Re: Et donc...
Posté par barmic 🦦 . En réponse au lien Git Koans. Évalué à 2.
Je pense qu'il est extrêmement fréquent de ne pas comprendre que les parents d'un commit fait parti de son identité et qu'un cherry-pick par exemple, c'est un nouveau commit qui n'a aucune relation avec sa copie d'origine au sens de l'arbre d'objet git.
C'est un peu le problème. git n'a pas était conçu pour être un gestionnaire de version simple à poser dans toutes les mains, mais un outils qui ne fait pas de concession pour la performance et taillé pour un projet précis. mercurial (que je préfère à git) est déjà un peu plus fait pour le tout venant même si je ne suis pas convaincu qu'un DCVS soit la panacée en soit. La gestion de version par les outils de traitement de texte bien que triviaux sont déjà une gageure pour beaucoup et j'ai l'impression que les outils qui s'en sortent le mieux pour ça sont ceux qui sauvegardent tout le temps et te permettent de revenir dans le temps de manière uniquement temporel (ils ne répondent qu'à des demandes de la forme "montre moi mes fichiers il y a 3h").
Les meilleurs outils pour voir ce que fait git que j'ai pu voir était des outils d'apprentissage où tu a l'écran divisé en 2 et ou tu vois en temps réel (par un rafraichissement régulier d'une vue) ce qui se passe dans ton graphe au fur et à mesure que tu lance des commandes et où tu peux revenir en arrière de manière instantanée et fiable via un bouton "back".
Après ça vient peut être d'avoir un esprit bottom-up ou top-down, mais ça me demande un effort considérable pour aller plus loin que ce qu'une GUI me propose.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll