Je passe le mot à mes adminsys : installez la GUI sur les serveurs :)
…même si cacher la misère sous une fenêtre ne résout pas le problème fondamental de la complexité du bousin (la plupart des collègues que je dépanne utilisent une GUI et n’ont jamais été confronté à SVN ou autres)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
J’avais oublié de revenir par ici. :( Heureusement, les commentaires ne sont pas encore clos.
Commençons par le cas simple que l’on occulte trop facilement… Quand les usagers poussent/tirent vers/depuis une forge, c’est bien par rapport à un dépôt central qui est sur un serveur ;-) Le principe demeure en l’absence de logiciel/programme de forge : les premiers dépôts que j’ai eu à mettre en place auprès d’entreprises qui n’entendaient pas encore les systèmes de version, c’était sur des dossiers partagés de serveurs (car le dépôt de référence peut être donné par un chemin du système, et pas que SSH ou HTTP… et ce n’est pas propre qu’à Git au passage.)
Mais j’imagine (mais j’en sais rien en fait) que la question est par rapport au dépôt de travail (enfin le local du point de vue des usagers de forges, car dans l’absolu rien n’empêche que les dépôts distants ne soient pas aussi des dépôts de travail —il m’est déjà arrivé de travailler ainsi en binôme ou en trinôme quand on n’a pas un serveur où archiver le travail commun.) Là aussi, il n’est pas exclu d’être sur un serveur (par opposition au poste personnel.)
J’ai travaillé dans une entreprise B…… qui a mis en place un système de CI/CD bien avant que n’apparaisse GitLab ou que la fonctionnalité soit fournie sur GitHub (où de toute façon cette entreprise ne peut pas être pour des contraintes juridiques.) Bon, le principe n’a pas beaucoup changé avec les outils/programmes actuels : il faut quand même cloner (ou rapatrier les commits) puis faire la popote indiquée. Dans le cas de cette entreprise B……, on fait juste du déploiement en recette/qualification/production. Je n’ai connu qu’un seul cas où il a fallu intervenir manuellement, ce qui nécessite de savoir utiliser la commande git pour revert sur un tag précis puis relancer manuellement le script de déploiement sur ce tag là. Habituellement, dans les rares cas de rollback, il suffisait de livrer une version corrective par dessus l’ancienne, mais sur ce coup là il a fallu rejouer une ancienne version après avoir nettoyé manuellement les serveurs concernés. Mais je m’éloigne, je voulais juste donner un exemple où il a fallu mettre les mains dans le cambouis et dans l’urgence.
Avant cela, j’ai connu deux entreprises qui utilisent etckeeper et dans la première le dépôt n’était que local au serveur. Bref, là, ça fonctionne bien comme un dépôt de travail sauf que les commits sont faits par un programme (chose que l’on peut retrouver aussi avec des applications personnelles de documentation par exemple) et qu’on est sur un serveur… Cela nous a sauvé la mise suite à certaines mises à jour (et la présence de cet outil m’a permis de faire entendre ma demande de les systématiser…) sauf qu’il faut connaitre la commande git et bien comprendre ce qu’on a configuré. Il n’y a pas que etckeeper et sa surcouche, on peut utiliser d’autres outils comme changetrack ou filemon, etc.
Je dirai que c’est un peu l’équivalent des solutions de dotfiles pour sysadmins, et on a des équivalents pour les netadmins (il y a Rancid et Oxidised que j’ai eu à mettre en œuvre, mais certainement bien d’autres que j’ignore.) Parfois ça peut comprendre ce qu’on a configuré. Il n’y a pas que etckeeper et sa surcouche, on peut utiliser d’autres outils comme changetrack ou filemon, etc.
Je dirai que c’est un peu l’équivalent des solutions de dotfiles pour sysadmins, et on a des équivalents pour les netadmins (il y a Rancid et Oxidised que j’ai eu à mettre en œuvre, mais certainement bien d’autres que j’ignore.) Parfois ça peut aller bien plus loin, comme bup…
Il y a les cas où on a du git sur le serveur mais pas pour y travailler (quoique ce soit parfois possible) ; en gros on y monte le dépôt comme on monterait un chemin réseau sauf qu’on a en prime toutes les versions en cas de besoin. Avec des collègues nous avons fait quelque chose du genre en pointant certains serveurs vers un dépôt Git et lui faire prendre sa recette par Ansible (beaucoup l’ignorent mais ça sait faire du pull, ici via un cron, et pas que du pull qui est le mode par défaut.) C’est un peu le fonctionnement que j’ai rencontré avec Puppet dans d’autres boîtes ; par contre ici, on n’est plus du tout dans le cas de dépôt où l’on commit, mais on a quand même du git sur le serveur.
Il y a certainement d’autres cas que je ne connais pas, et pour ce que je connais j’ai préférer me limiter à des choses auxquelles j’ai touchées. Il y a en tout cas plein de raisons d’avoir un dépôt Git sur un serveur.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Bah, il me semble que la question ne portait pas sur ton billet mais sur ma remarque
Je passe le mot à mes adminsys : installez la GUI sur les serveurs :)
Par contre, je vois assez peu de cas d'usage pour avoir Git sur un serveur, et encore moins pour aller y faire des opérations non triviales à la main.
J’ai énuméré des cas où j’ai vu du Git sur des serveurs. (premier point)
En général ça roule tout seul et on n’a pas besoin d’y toucher… Sauf quand il y a un incident (ou une requête urgente non prévue par les procédure) ; et (à la louche) deux fois sur trois ça peut se résoudre par des opérations plus ou moins triviales mais dans tous les cas manuellement. (second point)
Dès le départ, en parlant de serveurs et d’administration système, ce n’était déjà pas dans le cadre du billet. (ou peut-être là je ne l’ai pas perçu)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Quand à la question « comment savoir sure quelle branches je suis ? » quelqu'un te répond git rev-parse --abbrev-ref HEAD, tu n'a pas en face de toi un maitre de git, mais un connard. git branch, git status, git show HEAD, git log,… te donnent l'information de manière naturelle.
Et aussi retenez qu’une branche ou un tag, c’est juste une étiquette sur un commit, […]
Un commit est un diff + une référence sur son ou ses parents.
Ensuite il y a quelques commandes à connaître pour manipuler le graphe de commit. Pour commencer uniquement : commit, cherry-pick, rebase, merge, branch (et pas leurs usages avancés !). Puis au fur et à mesure de l’expérience étoffer avec les usages plus complexes de ses commandes, des rebases interactifs voir du reflog.
Utilisez une GUI !
Personnellement l'utilisation de la CLI me permet de capitaliser sur ma connaissance de zsh, j'ai immédiatement accès aux nouveautés de git (comme rebase --onto), je n'ai pas d'opération qui de manière aléatoire prennent du temps (changer le label d'un commit précédent par exemple si tu le fais en CLI tu sais pourquoi ça n'est pas instantanné si tu le fais dans intellij tu cris sur l'outil comme quoi il est bugué), je ne suis pas en environnement inconnu quand je m'en sert sur des machines qui n'ont pas d'écran (serveur pour gérer de la configuration ou rpi pour configuration ou compilation locale), je peux faire des manipulations avec le niveau de rafinement que je veux avec les raccourcis et des scripts.
Les gens utilisent bien ce qu'ils veulent (je n'aimerais pas qu'on me dise quoi utiliser donc je ne vais pas le faire), mais quand tu utilise de manière un minimum régulière un outil, je trouve dommage de passer à côté de ce que peut faire la CLI pour avoir une marche initiale plus simple, mais avoir au final pas mal de complexité derrière (parce qu'on ne profite pas des améliorations de l'outils, parce que c'est souvent bien moins documenté parce que faire quelque chose qui n'a pas était prévu par l'outil peut devenir une gageur quand c'est possible)
Un commit est un diff + une référence sur son ou ses parents.
É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.
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.
Par contre, un point qui visiblement est mal compris de ce billet et qui transparait dans ce que je comprends de tes remarques : le but du billet n’est absolument pas de dire « Utilisez une GUI pour utiliser Git, c’est plus simple, quitte à rester coincé dans les limites de cette GUI ». Le but du billet, c’est de dire : « 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 ». L’idée c’est de se servir d’une GUI au début de son apprentissage de Git, pour arriver à avoir une vue d’ensemble de l’outil – qui est difficile à avoir en CLI pour toutes les raisons données dans le billet – et, à partir de là, pouvoir utiliser n’importe quel outil facilement avec pour seule marche l’apprentissage de la « grammaire » de l’outil en question (et pas celle de Git). Il faudrait que j’arrive à comprendre ce qui provoque ces réactions pour corriger le billet en fonction.
É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.
j'ai immédiatement accès aux nouveautés de git (comme rebase --onto)
Désolé, j'ai ri: prendre cette commande vieille d'au moins 11 ans comme exemple de nouveauté…
J'espère que tu ne viens pas de la découvrir sinon ton argumentaire tombe à l'eau…
Et plus sérieusement, on ne peut opposer la ligne de commande et les GUI. Certaines choses sont plus faciles avec l'un et d'autres avec l'autre. Chacun choisit donc avec lequel il est plus à l'aise.
Et les GUIs peuvent aussi permettre de découvrir certaines fonctionnalités d'un outil qui sinon resteraient cachés dans une donc ou un changelog qu'on ira jamais lire (pour diverses raisons. Une pouvant être qu'on la maîtrise suffisamment).
Désolé, j'ai ri: prendre cette commande vieille d'au moins 11 ans comme exemple de nouveauté…
C'est surtout une réécriture du commentaire pour laquelle j'ai pas bien relu. Initialement l'exemple était pour une fonctionnalité que je n'ai jamais vu ailleurs que dans l'outil de base. Mais au delà de ta condescendance, il m'arrive d'apprendre récemment des choses de git qui pourtant existent depuis probablement l'origine. D'ailleurs je ne connais pas l'option --onto de rebase depuis si longtemps que ça, je l'ai découvert dans une release note il y a quelques années.
Et les GUIs peuvent aussi permettre de découvrir certaines fonctionnalités d'un outil qui sinon resteraient cachés dans une donc ou un changelog qu'on ira jamais lire (pour diverses raisons. Une pouvant être qu'on la maîtrise suffisamment).
D’expérience j'ai l'impression que les interfaces ont tendance à cacher au contraire les fonctionnalités et que ça demande bien beaucoup plus d'effort pour aller au delà de ce qui est considéré comme le case d'utilisation principal à la conception de l'interface.
Franchement quand on ne connait pas git, utiliser une GUI c'est pas une bonne idée.
Dans ma boite quand je suis arrivé presque tous les devs utilisaient une GUI pour Git, et il y avait pleins de conflits, des commits qui n'étaient pas sur la bonne branche ect…
Je leur ai donnée une petite formation sur Git en CLI, et ils se sont tous mis à la CLI et depuis on a rarement des problèmes.
Alors oui la CLI ça peut faire peur au début mais au final tu maitrises et comprends petit à petit ce que tu fais.
# Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 0.
Utilisez une GUI !
Et aussi retenez qu’une branche ou un tag, c’est juste une étiquette sur un commit, Git n’est pas SVN ! (rapport à « Only the Gods »).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et donc…
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je passe le mot à mes adminsys : installez la GUI sur les serveurs :)
…même si cacher la misère sous une fenêtre ne résout pas le problème fondamental de la complexité du bousin (la plupart des collègues que je dépanne utilisent une GUI et n’ont jamais été confronté à SVN ou autres)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
La question n'est pas tellement de cacher la misère.
Par contre, je vois assez peu de cas d'usage pour avoir Git sur un serveur, et encore moins pour aller y faire des opérations non triviales à la main.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et donc…
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 06 janvier 2024 à 04:05.
J’avais oublié de revenir par ici.
:(Heureusement, les commentaires ne sont pas encore clos.Commençons par le cas simple que l’on occulte trop facilement… Quand les usagers poussent/tirent vers/depuis une forge, c’est bien par rapport à un dépôt central qui est sur un serveur
;-)Le principe demeure en l’absence de logiciel/programme de forge : les premiers dépôts que j’ai eu à mettre en place auprès d’entreprises qui n’entendaient pas encore les systèmes de version, c’était sur des dossiers partagés de serveurs (car le dépôt de référence peut être donné par un chemin du système, et pas que SSH ou HTTP… et ce n’est pas propre qu’à Git au passage.)Mais j’imagine (mais j’en sais rien en fait) que la question est par rapport au dépôt de travail (enfin le local du point de vue des usagers de forges, car dans l’absolu rien n’empêche que les dépôts distants ne soient pas aussi des dépôts de travail —il m’est déjà arrivé de travailler ainsi en binôme ou en trinôme quand on n’a pas un serveur où archiver le travail commun.) Là aussi, il n’est pas exclu d’être sur un serveur (par opposition au poste personnel.)
J’ai travaillé dans une entreprise B…… qui a mis en place un système de CI/CD bien avant que n’apparaisse GitLab ou que la fonctionnalité soit fournie sur GitHub (où de toute façon cette entreprise ne peut pas être pour des contraintes juridiques.) Bon, le principe n’a pas beaucoup changé avec les outils/programmes actuels : il faut quand même cloner (ou rapatrier les commits) puis faire la popote indiquée. Dans le cas de cette entreprise B……, on fait juste du déploiement en recette/qualification/production. Je n’ai connu qu’un seul cas où il a fallu intervenir manuellement, ce qui nécessite de savoir utiliser la commande
gitpour revert sur un tag précis puis relancer manuellement le script de déploiement sur ce tag là. Habituellement, dans les rares cas de rollback, il suffisait de livrer une version corrective par dessus l’ancienne, mais sur ce coup là il a fallu rejouer une ancienne version après avoir nettoyé manuellement les serveurs concernés. Mais je m’éloigne, je voulais juste donner un exemple où il a fallu mettre les mains dans le cambouis et dans l’urgence.Avant cela, j’ai connu deux entreprises qui utilisent
etckeeperet dans la première le dépôt n’était que local au serveur. Bref, là, ça fonctionne bien comme un dépôt de travail sauf que les commits sont faits par un programme (chose que l’on peut retrouver aussi avec des applications personnelles de documentation par exemple) et qu’on est sur un serveur… Cela nous a sauvé la mise suite à certaines mises à jour (et la présence de cet outil m’a permis de faire entendre ma demande de les systématiser…) sauf qu’il faut connaitre la commandegitet bien comprendre ce qu’on a configuré. Il n’y a pas queetckeeperet sa surcouche, on peut utiliser d’autres outils commechangetrackoufilemon, etc.Je dirai que c’est un peu l’équivalent des solutions de dotfiles pour sysadmins, et on a des équivalents pour les netadmins (il y a Rancid et Oxidised que j’ai eu à mettre en œuvre, mais certainement bien d’autres que j’ignore.) Parfois ça peut comprendre ce qu’on a configuré. Il n’y a pas que
etckeeperet sa surcouche, on peut utiliser d’autres outils commechangetrackoufilemon, etc.Je dirai que c’est un peu l’équivalent des solutions de dotfiles pour sysadmins, et on a des équivalents pour les netadmins (il y a Rancid et Oxidised que j’ai eu à mettre en œuvre, mais certainement bien d’autres que j’ignore.) Parfois ça peut aller bien plus loin, comme bup…
Il y a les cas où on a du git sur le serveur mais pas pour y travailler (quoique ce soit parfois possible) ; en gros on y monte le dépôt comme on monterait un chemin réseau sauf qu’on a en prime toutes les versions en cas de besoin. Avec des collègues nous avons fait quelque chose du genre en pointant certains serveurs vers un dépôt Git et lui faire prendre sa recette par Ansible (beaucoup l’ignorent mais ça sait faire du pull, ici via un cron, et pas que du pull qui est le mode par défaut.) C’est un peu le fonctionnement que j’ai rencontré avec Puppet dans d’autres boîtes ; par contre ici, on n’est plus du tout dans le cas de dépôt où l’on commit, mais on a quand même du git sur le serveur.
Il y a certainement d’autres cas que je ne connais pas, et pour ce que je connais j’ai préférer me limiter à des choses auxquelles j’ai touchées. Il y a en tout cas plein de raisons d’avoir un dépôt Git sur un serveur.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
Bravo, tu es passé complètement à côté du propos de mon billet.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et donc…
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Bah, il me semble que la question ne portait pas sur ton billet mais sur ma remarque
J’ai énuméré des cas où j’ai vu du Git sur des serveurs. (premier point)
En général ça roule tout seul et on n’a pas besoin d’y toucher… Sauf quand il y a un incident (ou une requête urgente non prévue par les procédure) ; et (à la louche) deux fois sur trois ça peut se résoudre par des opérations plus ou moins triviales mais dans tous les cas manuellement. (second point)
Dès le départ, en parlant de serveurs et d’administration système, ce n’était déjà pas dans le cadre du billet. (ou peut-être là je ne l’ai pas perçu)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et donc…
Posté par flagos . Évalué à 8.
Ou utilisez magit !
https://emacsrocks.com/e17.html
[^] # Re: Et donc…
Posté par madhatter (site web personnel) . Évalué à 3.
Complètement d'accord avec toi. Magit c'est tellement bien !
There is no spoon...
[^] # Re: Et donc…
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Coucou qui veut voir magit?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et donc…
Posté par barmic 🦦 . Évalué à 9.
Quand à la question « comment savoir sure quelle branches je suis ? » quelqu'un te répond
git rev-parse --abbrev-ref HEAD, tu n'a pas en face de toi un maitre de git, mais un connard.git branch,git status,git show HEAD,git log,… te donnent l'information de manière naturelle.Un commit est un diff + une référence sur son ou ses parents.
Ensuite il y a quelques commandes à connaître pour manipuler le graphe de commit. Pour commencer uniquement : commit, cherry-pick, rebase, merge, branch (et pas leurs usages avancés !). Puis au fur et à mesure de l’expérience étoffer avec les usages plus complexes de ses commandes, des rebases interactifs voir du reflog.
Personnellement l'utilisation de la CLI me permet de capitaliser sur ma connaissance de zsh, j'ai immédiatement accès aux nouveautés de git (comme
rebase --onto), je n'ai pas d'opération qui de manière aléatoire prennent du temps (changer le label d'un commit précédent par exemple si tu le fais en CLI tu sais pourquoi ça n'est pas instantanné si tu le fais dans intellij tu cris sur l'outil comme quoi il est bugué), je ne suis pas en environnement inconnu quand je m'en sert sur des machines qui n'ont pas d'écran (serveur pour gérer de la configuration ou rpi pour configuration ou compilation locale), je peux faire des manipulations avec le niveau de rafinement que je veux avec les raccourcis et des scripts.Les gens utilisent bien ce qu'ils veulent (je n'aimerais pas qu'on me dise quoi utiliser donc je ne vais pas le faire), mais quand tu utilise de manière un minimum régulière un outil, je trouve dommage de passer à côté de ce que peut faire la CLI pour avoir une marche initiale plus simple, mais avoir au final pas mal de complexité derrière (parce qu'on ne profite pas des améliorations de l'outils, parce que c'est souvent bien moins documenté parce que faire quelque chose qui n'a pas était prévu par l'outil peut devenir une gageur quand c'est possible)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
É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.
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.
Par contre, un point qui visiblement est mal compris de ce billet et qui transparait dans ce que je comprends de tes remarques : le but du billet n’est absolument pas de dire « Utilisez une GUI pour utiliser Git, c’est plus simple, quitte à rester coincé dans les limites de cette GUI ». Le but du billet, c’est de dire : « 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 ». L’idée c’est de se servir d’une GUI au début de son apprentissage de Git, pour arriver à avoir une vue d’ensemble de l’outil – qui est difficile à avoir en CLI pour toutes les raisons données dans le billet – et, à partir de là, pouvoir utiliser n’importe quel outil facilement avec pour seule marche l’apprentissage de la « grammaire » de l’outil en question (et pas celle de Git). Il faudrait que j’arrive à comprendre ce qui provoque ces réactions pour corriger le billet en fonction.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et donc…
Posté par barmic 🦦 . É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
[^] # Re: Et donc…
Posté par cosmocat . Évalué à 2.
Désolé, j'ai ri: prendre cette commande vieille d'au moins 11 ans comme exemple de nouveauté…
J'espère que tu ne viens pas de la découvrir sinon ton argumentaire tombe à l'eau…
Et plus sérieusement, on ne peut opposer la ligne de commande et les GUI. Certaines choses sont plus faciles avec l'un et d'autres avec l'autre. Chacun choisit donc avec lequel il est plus à l'aise.
Et les GUIs peuvent aussi permettre de découvrir certaines fonctionnalités d'un outil qui sinon resteraient cachés dans une donc ou un changelog qu'on ira jamais lire (pour diverses raisons. Une pouvant être qu'on la maîtrise suffisamment).
[^] # Re: Et donc…
Posté par barmic 🦦 . Évalué à 3.
C'est surtout une réécriture du commentaire pour laquelle j'ai pas bien relu. Initialement l'exemple était pour une fonctionnalité que je n'ai jamais vu ailleurs que dans l'outil de base. Mais au delà de ta condescendance, il m'arrive d'apprendre récemment des choses de git qui pourtant existent depuis probablement l'origine. D'ailleurs je ne connais pas l'option --onto de rebase depuis si longtemps que ça, je l'ai découvert dans une release note il y a quelques années.
D’expérience j'ai l'impression que les interfaces ont tendance à cacher au contraire les fonctionnalités et que ça demande bien beaucoup plus d'effort pour aller au delà de ce qui est considéré comme le case d'utilisation principal à la conception de l'interface.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et donc…
Posté par nishiki . Évalué à 1.
Franchement quand on ne connait pas git, utiliser une GUI c'est pas une bonne idée.
Dans ma boite quand je suis arrivé presque tous les devs utilisaient une GUI pour Git, et il y avait pleins de conflits, des commits qui n'étaient pas sur la bonne branche ect…
Je leur ai donnée une petite formation sur Git en CLI, et ils se sont tous mis à la CLI et depuis on a rarement des problèmes.
Alors oui la CLI ça peut faire peur au début mais au final tu maitrises et comprends petit à petit ce que tu fais.
[^] # Re: Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
C’est bien de lire les liens quand il y en a, aussi.
La connaissance libre : https://zestedesavoir.com
# git switch
Posté par Glandos . Évalué à 3.
https://stevelosh.com/blog/2013/04/git-koans/#s2-one-thing-well
J'ai découvert
git switchpour commencer à résoudre ce problème. C'est pas mal.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.