Licence CC BY

Git: Il paraît que la GUI est notre amie

spoiler, oui

Publié :
Auteur :
Catégorie :
Temps de lecture estimé : 13 minutes

Il y a peu, @spacefox a écrit un billet Git: La GUI est votre amie qui est loin d’être passée inaperçu à en juger le nombre de commentaires mais aussi les statistiques publiées dans le récap communautaire d’avril.

Je voulais ajouter un commentaire à ce billet mais au fur et à mesure que je l’écrivais j’ai constaté deux choses : il était très long et à la fin il manquait de structure.

Du coup je vais transformer le commentaire en billet, un peu plus structuré.

La question qui me turlupine et qui a été posée tant dans le billet de @spacefox que dans les commentaire c’est :

 La question à 1 million de dollars

 Est-ce qu’on comprend mieux ce qu’on fait quand on utilise la GUI (resp la CLI)?

Quel outil pour Git?

D’où l’on vient

J’ai appris à utiliser Git car j’ai voulu participer au projet Atoum créé par @mageekguy. A cette époque j’étais en 2ème année d’ingénieure et je ne connaissais qu’un seul système de gestion de version : SVN.

Lorsque je fus accueillie sur github avec des demande style "fais un rebase" ou "tire la branche de dev plutôt que master" j’étais totalement perdu ! On peut le dire : je ne comprenais pas ce que je faisais.

A cette époque j’utilisais deux outils :

  • le plugin Git de Netbeans pour faire du put, du pull et des branches
  • la CLI pour copier/coller des commandes qu’on me disait de faire.

Où l’on est

Puis le temps a un peu passé, et zeste de savoir a même commencé son développement et là j’ai commencé à apprendre à utiliser git. Mieux, au détour d’un autre projet étudiant, un enseignant m’a invité à regarder le fonctionnement théorique de git pour le comprendre. Voir que c’était un système de fichier à part entière, ce qu’était un commit, pourquoi on avait la commande reset et la commande revert.

Comme cela a une importance pour la suite du billet, on peut aussi noter que c’est là que j’ai appris la notion d’état "unstash", "stashed" et "committed". Même si je ne saisissais pas bien l’intérêt dans la vie de tous les jours : mes recherches se concentraient sur l’aspect théorique de git.

Notons que c’est là que j’ai vraiment compris ce que signifiait "git est décentralisé" et ce qu’était un "repo git". Les tuto qui t’expédient ça en mode "tu as le dépôt distant et le dépôt local" ne sont pas incorrects, mais ils ne te présentent pas vraiment la puissance et l’élégance de la chose du coup tu ne pige pas qu’il faut retenir le concept.

A partir de là j’ai une utilisation de git qui est vraiment très hybride :

  • pour merger => GUI (que ça soit meld quand j’ai rien ou l’interface jetbrains, faut comprendre qu’à la base j’avais installé intellij sur mon poste pro à côté d’éclipse juste pour la partie Git)
  • gérer les fichiers à inclure ou pas dans un commit => GUI, ça parraît con comme ça, mais le résultat en terminal de git status n’est pas réellement lisible dans la vie de tous les jours où tu dois faire des refacto
  • faire un rebase intéractif ou non => CLI
  • toutes les autres opérations courantes => le premier outil que j’ai sous la main

Où l’on va

J’ai eu du mal à bien écrire la partie "où l’on est" car je suis nettement en train d’abandonner la CLI à cause de l’ergonomie de pycharm et IntelliJ qui me permettent de faire mieux, plus rapidement et en réduisant le nombre d’erreurs.

Cet aspect est précisément ce qui a déclenché l’écriture de ce billet et il se cristalise dans les deux anecdotes qui vont suivre.

Anecdote 1 : let's stash clem'

La première des anecdotes est un cas où j’ai découvert une fonctionnalité de git par la ligne de commande, mais que je ne l’ai vraiment comprise que plus tard grâce à l’utilisation d’une GUI.

L’histoire se déroule alors que @cepus gère le déploiement de zeste de savoir sur la béta. Il se rend compte qu’il y a un gros problème depuis notre dernier update d’un outil : notre connexion à la bdd ne se fait plus.

Problème : en local, même avec une stack identique à la béta, ça passe. D’ailleurs ça passe aussi sur notre CI.

Commence alors une investigation qui se termine par la modification directe sur le serveur de béta d’un fichier de code python pour rendre fonctionnelle notre connexion. S’en suit une PR, qui est mergée et cepus le lendemain cepus tente de faire le déploiement de la nouvelle version.

Et là, git nous dit qu’il y a des conflits qu’on ne peut pas tirer la branche sur le github et qu’il faut commiter les changements.

Sachant qu’une PR avait été faite pour pousser les changements utiles, je dis à cepus "aller, git reset --hard et on pourra tirer la branche.

Cepus me répond alors qu’il est préférable de simplement faire git stash pour ne pas perdre mes modifications et passer à la suite.

Là je suis perdu, je ne vois pas comment on peut avoir les deux à la fois sans faire un commit. Mais la commande, de manière assez magique, fonctionne : le dépôt revient dans le même état que si j’avais fait un commit et avec une commande que je ne connais pas, vhf arrive à me fournir à la volée le patch à appliquer si ça marche toujours pas.

Et pendant deux ans, cette expérience me laissera perplexe.

Jusqu’à ce qu’IntelliJ mette à jour son interface de "stash/unstash" (je ne sais plus quelle version était impactée) et fasse un article sur la manière d’utiliser cette fonctionnalité.

Pour info c’est Clic droit > git > repository > stash changes (ou unstash changes).

On a déjà une première info : un stash agit au niveau du dépôt et il a une opération inverse (unstash), d’un coup tout paraît moins magique.

Mais le gros truc qui a rendu tout clair dans mon esprit c’est le petit prompt qui s’ouvre alors :

Prompt de stash
Prompt de stash

Ce prompt a un avantage clair et net : il me donne un contexte (le dépôt et la branche) ainsi que la possibilité d’entrer un message. Et là tout est clair on est dans une sorte de pseudo commit qui va faire tout le boulot du commit MAIS ne va pas s’intégrer à l’historique.

Et un coup d’oeil à Unstash Changes t’aidera à comprendre l’impact de tes actions. Et comme tu as été plus ou moins obligé d’entrer un message, au moment de faire ton "unstash" tu sais ce que tu vas appliquer. Au pire la GUI te permet d’avoir un petit diff en preview.

En fait ce que je retiens de cette anecdote c’est qu’une GUI a une logique de navigation là où une CLI a une logique à plat. La logique de navigation ajoute un contexte qui facilite la compréhension MAIS elle peut parfois rendre lourd le fonctionnement de la fonctionnalité.

Cette logique de navigation peut paraître magique à une personne qui a l’habitude de configurer l’exécution de sa ligne de commande avec les options qui vont bien mais utiliser une GUI n’empêche pas de comprendre les concept, au contraire, en donnant du contexte elle facilite l’autonomisation.

Anecdote 2: All your rebase are belong to us

Ah le rebase, c’est la seule opération qui m’a très longtemps bloqué sur la CLI car j’avais cette impression de comprendre ce que ça faisait quand on était en CLI alors qu’en fait c’était juste que j’avais déjà compris le concept de base et que du coup je n’utilisais que les formes les plus simples de la commande.

C’est encore sur zds que le noeud du problème se posera, et encore une fois il faudra un laps de temps conséquent pour que la GUI apporte un intérêt.

Or donc, nous sommes en plein développement des tribunes. Gustavi a galéré comme un dingue et m’a refilé le bébé. D’autres membres viennent alors m’aider. Mais voilà, un gros fix sur le module de tuto vient d’avoir lieu qui touche profondément au code de la publication. Et les tribunes, ça touche aussi énormément à ce code. Il faut rebaser.

Je commence à faire ma petite commande git rebase upstream/dev et là… c’est horrible.

Conflits de partout, impossible de savoir comment je dois appliquer les différences les unes par rapport aux autres, je passe 3 heures et à la fin ça bug.

Un développeur de zds (je ne sais plus qui, désolé, si tu te reconnais, bah voilà c’est de toi que je parle) me vient alors en aide et après une dizaines de minutes d’analyse de l’historique git me balance une commande imbitable qui ressemble un peu à git rebase --onto sha-commit1 sha-commit2. Je lance la commande et… là les conflits deviennent tellement faciles à résoudre que je n’y passe que 10 minutes et ça plante pas.

Cette commande était magique, et je vais passer pas mal de temps à essayer de comprendre :

  • comment elle a fonctionné;
  • comment je pourrais moi-même faire une telle commande plus tard.

Je pense qu’aujourd’hui j’en serais capable, mais je ne suis pas très confiant notamment sur l’ordre des commits en argument, et au pire j’ai pas souvent besoin de ça.

Sauf qu’après l’article de @spacefox, j’ai été pris de curiosité et j’ai été voir comment on pouvait faire un rebase sur pycharm/IntelliJ (c’est jouissif).

Et là on a un prompt, qui nous présente trois paramètres :

  • commit to rebase onto
  • commit to rebase from
  • interractive (essayez le rebase interactif avec pycharm, c’est juste énorme, vous allez abandonner vim après ça)

Et chacun de ces éléments a un tooltip d’aide qui t’explique très bien à quoi ça sert. Le manuel de la commande man est pourtant très complet, mais justement il est tellement complet qu’on s’y perd.

Alors oui, aujourd’hui je sais à quoi sert "commit to rebase from", je sais prévoir le résultat qu’il aura, et je sais pourquoi je n’en ai pas besoin au jour le jour. Et l’usage base que de git rebase upstream/dev que j’avais me masquait tout ça.

Cette anecdote là montre qu’on peut tout à fait ne pas comprendre ce qu’on fait avec une CLI, que la GUI peut (et c’est loin d’être systématique) présenter les informations d’une manière qui la rend bien plus compréhensible.

Les GUI que j'ai utilisé

  • Le plugin netbeans => très lourd, et fait beaucoup de choses bloquantes, mais bon netbeans c’est un peu vieux comme IDE
  • Turtoise Git => fuyez, sincèrement, entre anti patern (on est sur du svn like), une interface de fusion qui est pas du tout prédictible et une visualisation qui n’apporte pas d’info, ça vois fera perdre du temps
  • Source tree => c’est sympa, quand vous avez un seul remote, sinon ça devient trop chargé. En soit ce qui m’a fait oublier sourcetree c’est que son interface de merge est pas pratique, mes collègues sont obligés de gérer les conflits en copiant/collant du code tellement l’interface fait mal son taf.
  • IntelliJ/pycharm => ma favorite, elle est en plus parfaitement intégrée. Le plus gros reproche que je lui fais c’est l’option "commit and push" qui te rouvre un prompt après, j’oublie trop souvent de le valider, ce qui signifie qu’il y a un problème d’ergonomie. Ah et aussi, comment tu peux deviner que "git blame" se transforme en "annotate"?

16 commentaires

faire un rebase intéractif ou non => CLI

GUI non, d’après ce que tu dis ensuite ?

Sinon, en vrai IntelliJ/Jetbrains a toujours géré le stash… à sa sauce. Depuis très longtemps ils ont une fonctionnalité nommée « shelf » qui fait la même chose, mais en mieux et en plus puissant. Ils ont ajouté le stash récemment (1 ou 2 ans ? la flemme de vérifier) pour compatibilité avec d’autres clients Git sur le même dépôt. C’est sans doute pour ça que son intégration n’est pas évidente, il est là « au cas où ».

Pour la même raison ils ont ajouté le support du staging dans Git (il y a vraiment des gens qui se servent de ce truc d’ailleurs ?)

GUI non, d’après ce que tu dis ensuite ?

en vrai c’est super récent que j’utilise la GUI pour rebase du coup j’ai encore majoritairement le "réflex" CLI, surtout pour zds.

+0 -0

Quand je lis ton billet, je me dis qu’en fait, le vrai frein à la compréhension est que Git est un outil complexe qui demande de consacrer un peu de temps à comprendre comment il fonctionne pour ne pas faire n’importe quoi et être efficace avec. Ça me fait dire que la question

Est-ce qu’on comprend mieux ce qu’on fait quand on utilise la GUI (resp la CLI)?

n’est pas du tout pertinente. On comprend mieux quand on réfléchit à ce qu’on fait et qu’on prend la peine de lire de la documentation sur le sujet. Peu importe qu’on utilise la CLI ou la GUI, si on tape des commandes sans les comprendre ou qu’on clique un peu au pif en espérant que ça va faire ce qu’on veut, ça va vite coincer. La seule différence est que la GUI facilite un peu l’exploration, mais en revers peut donner un peu trop de confiance à l’utilisateur qui ne se rend pas compte qu’il ne comprend pas certains concepts fondamentaux. La CLI d’un autre côté à une courbe d’apprentissage plus pentue, mais comme sur un outil comme Git il faut passer par un apprentissage quoiqu’il arrive pour s’en servir sérieusement, c’est un problème relativement mitigé.

Typiquement, quand j’ai lu ça :

Cepus me répond alors qu’il est préférable de simplement faire git stash pour ne pas perdre mes modifications et passer à la suite.

Là je suis perdu, je ne vois pas comment on peut avoir les deux à la fois sans faire un commit. Mais la commande, de manière assez magique, fonctionne : le dépôt revient dans le même état que si j’avais fait un commit et avec une commande que je ne connais pas, vhf arrive à me fournir à la volée le patch à appliquer si ça marche toujours pas.

Et pendant deux ans, cette expérience me laissera perplexe.

Je dois dire que je suis resté un peu perplexe. Un type te donne une commande que tu connais pas, dont l’action te parait floue, et tu ne vas pas lire la doc ? git stash --help donne une description plutôt parlante :

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

The modifications stashed away by this command can be listed with git stash list, inspected with git stash show, and restored (potentially on top of a different commit) with git stash apply. Calling git stash without any arguments is equivalent to git stash push. A stash is by default listed as "WIP on branchname …", but you can give a more descriptive message on the command line when you create one.

Difficile de faire plus clair, et c’est complet. Perso quand je vois ta fenêtre de "Stash", je comprends pas du tout ce que ça va faire concrètement, à part que le nom lui-même donne un indice… D’ailleurs, on voit ici qu’avec les sous-commandes, la CLI n’est très certainement pas "à plat". Dans ta GUI, il y a le niveau "repository" en plus (qui doit regrouper tellement de trucs que je suis pas sur de voir ce qu’il apporte en compréhension), par contre la GUI découple stash push et stash pop (ou apply, va savoir ce que unstash fait…) et donc empêche de voir que le stash est une pile FILO.

Même chose avec rebase, tu as dans la description de git rebase --help des petits arbres pour expliquer comment et pourquoi utiliser onto. La CLI de git manque cruellement d’unité est a des bizarreries dégueulasses, mais par contre la doc est là.

L’argument de dire que le man est complet ne tient pas d’ailleurs, t’as clairement pas besoin de tout lire. La section description est ultra parlante. T’as quelque paragraphes un peu techniques dans celui de rebase mais ils ne sont pas cruciaux du tout… Et si vraiment elle te rebute, il y a la page rebase du Gitbook (perso je comprends pas comment on peut utiliser git au quotidien et ne jamais prendre la peine de se cogner le Git book… :-°).

Je trouve que la vraie conclusion de ton billet, c’est pas que la GUI est mieux ou moins bien que la CLI pour apprendre Git (je pense que la réponse à cette question est tellement subjective que ça la rend inintéressante), c’est que la maîtrise d’un outil comme Git ne tombera pas du ciel. Si on ne prend pas un peu de temps pour comprendre qu’un dépôt Git est un arbre orienté de commits et comment jouer avec cet arbre, on agira toujours au pif.


Pour la même raison ils ont ajouté le support du staging dans Git (il y a vraiment des gens qui se servent de ce truc d’ailleurs ?)

Pour être sûr, tu demandes si des gens qui utilisent la CLI se servent de la staging area ? Je me demande plutôt si il y a des gens qui ne s’en servent pas. o_O Si ça t’intéresse je peux détailler mes cas d’usages.

Depuis très longtemps ils ont une fonctionnalité nommée « shelf » qui fait la même chose, mais en mieux et en plus puissant

Tu pourrais détailler les différences qui te font dire que c’est mieux et plus puissant que le stash ? Si j’ai besoin d’un truc plus puissant que le stash, je fais une branche à la volée avec un commit. Ça coûte rien et après t’as accès à tous les outils de manipulations classiques de branches pour jouer avec. Le stash, c’est juste une pile à vaisselle sale très temporaire.

Édité par adri1

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+3 -0

Le coup du stash est vraiment utile car il montre une chose : lorsque tu as une CLI il faut que tu sortes de ta logique "comment résoudre mon problème?" pour aller comprendre comment ça marche en première lecture puis vérifier comment appeler en seconde lecture et à chaque fois soit dans un bash différent soit en supprimant le début de la commande que tu viens d’écrire.

La GUI facilite l’exploration car on peut avoir l’aide soit sous forme de contexte, soit sous forme d’infobulle pour concevoir notre appel. Je n’arrive pas à comprendre comment la GUI aura " en revers [de] donner un peu trop de confiance à l’utilisateur qui ne se rend pas compte qu’il ne comprend pas certains concepts fondamentaux" là où la CLI ne l’aurait pas. Justement le cas du rebase est typique. J’ai confiance en mon rebase en CLI et je chie énormément sur comment je veux l’utiliser dès que c’est plus complexe (parce que bon, soyons clairs entre le man qui te donne des A-B-C et toi qui doit manipuler des graphes multirepo où parfois les pointeurs ne tiennent pas ensemble sur le même écran c’est pas du tout la même chose si tu as pas de contexte). J’étais capable de faire mon rebase avant de passer par la GUI, je pers juste inutillement confiance car il faut se souvenir des options, de l’ordre des arguments et en plus pour faire du "check" c’est un peu plus lourd.

Si j’ai fait mon billet c’est que justement à chaque fois pour ces deux anecdotes j’ai eu un coup de "ah mais en fait ça j’avais pas compris" puis j’ai cherché, j’ai trouvé et… j’ai jamais utilisé le stash et le rebase —onto avec la CLI car c’est trop complexe de manipuler.

L’argument "le stash est un FILO et la GUI le cache" est selon moi un faux argument : dans les faits tu peux tout à fait te passer de cet aspect FILO avec un bon set d’alias. Alias que tu vas probablement recopier quelque part sur stackoverflow d’ailleurs. Du coup à l’usage (et c’est ce qui est important), que cette particularité soit caché par une interface qui te permet d’apply le stash qui est au milieu de la pile, franchement osef. C’est même bien plus pratique.

+1 -0

Pour être sûr, tu demandes si des gens qui utilisent la CLI se servent de la staging area ? Je me demande plutôt si il y a des gens qui ne s’en servent pas. o_O Si ça t’intéresse je peux détailler mes cas d’usages.

Je me demande si des gens qui utilisent Git se servent vraiment de la staging area, oui. Parce que je me suis rendu compte que depuis que j’utilise un client qui ne l’intègre pas, elle me manque tellement peu que je ne sais même plus ce que j’en faisait avant !

Pour être sûr, tu demandes si des gens qui utilisent la CLI se servent de la staging area ? Je me demande plutôt si il y a des gens qui ne s’en servent pas. o_O Si ça t’intéresse je peux détailler mes cas d’usages.

Je me demande si des gens qui utilisent Git se servent vraiment de la staging area, oui. Parce que je me suis rendu compte que depuis que j’utilise un client qui ne l’intègre pas, elle me manque tellement peu que je ne sais même plus ce que j’en faisait avant !

SpaceFox

Perso je m’en sers comme d’une sorte de sauvegarde / brouillon de commit, pour marquer une partie du travail comme terminé en quelque sorte. Par exemple je vais stage les lignes modifiées d’un fichier qui concernent la tâche en cours et auxquels je ne touche plus, et garder les modifs locales qui rajoutent un log de debug… Je ne stage jamais un fichier en entier, c’est le meilleur moyen de commit son super log "crotte de bique, devrait pas être là".

Donc pour moi c’est 100% du temps.

+1 -0

Le coup du stash est vraiment utile car il montre une chose : lorsque tu as une CLI il faut que tu sortes de ta logique "comment résoudre mon problème?" pour aller comprendre comment ça marche en première lecture puis vérifier comment appeler en seconde lecture et à chaque fois soit dans un bash différent soit en supprimant le début de la commande que tu viens d’écrire.

Je suis désolé, je ne comprends pas cette phrase. Les mots indépendamment, oui, mais ensemble dans une phrase je vois pas ce que tu essaies de dire. En fait, je pense qu’on a fondamentalement une façon différente d’aborder l’apprentissage d’un outil de façon générale. Perso, je me suis cogné le git book avant d’avoir à utiliser git sur un vrai projet.

La GUI facilite l’exploration car on peut avoir l’aide soit sous forme de contexte, soit sous forme d’infobulle pour concevoir notre appel. Je n’arrive pas à comprendre comment la GUI aura " en revers [de] donner un peu trop de confiance à l’utilisateur qui ne se rend pas compte qu’il ne comprend pas certains concepts fondamentaux" là où la CLI ne l’aurait pas.

Ton exemple du rebase est justement un bon exemple. Tu t’amuses un peu avec la GUI, et en tâtonnant sans trop comprendre, tu vas arriver à faire ce que tu veux en lisant les indices qui te sont tendus sur un plateau. Utilise rebase en CLI, et tu vas te manger complètement si t’as pas complètement compris ce qui se passe et quelle opération tu es en train de faire. C’est probablement rarement un vrai problème en pratique si l’interface est bien faite et offre les bonnes explications au bon moment, mais je ne suis pas sûr que ce soit le cas général de toutes les GUI.

parce que bon, soyons clairs entre le man qui te donne des A-B-C et toi qui doit manipuler des graphes multirepo où parfois les pointeurs ne tiennent pas ensemble sur le même écran c’est pas du tout la même chose si tu as pas de contexte.

Là, c’est une question de capacité d’abstraction après (d’ailleurs tu peux remplacer les lettres par des arbres entiers sans rien changer conceptuellement puisqu’ils sont orientés…). Manipuler des arbres un peu grand dans sa tête, c’est pas forcément facile, mais là on retombe dans le critère subjectif. Perso, j’aime bien justement que les exemples soient simples et bien lisibles, parce qu’après c’est ultra simple à généraliser sur un arbre plus complet.

Si j’ai fait mon billet c’est que justement à chaque fois pour ces deux anecdotes j’ai eu un coup de "ah mais en fait ça j’avais pas compris" puis j’ai cherché, j’ai trouvé et… j’ai jamais utilisé le stash et le rebase —onto avec la CLI car c’est trop complexe de manipuler.

Et justement, ma réponse à ça, c’est que le fait que tu n’avais pas compris ne vient pas du fait que tu utilisais la CLI ou la GUI, il vient du fait que tu n’as pas pris la peine de lire la doc. Que ce soit celle du man ou celle dans les infobulles de ta GUI ne change rien.

L’argument "le stash est un FILO et la GUI le cache" est selon moi un faux argument : dans les faits tu peux tout à fait te passer de cet aspect FILO avec un bon set d’alias. Alias que tu vas probablement recopier quelque part sur stackoverflow d’ailleurs. Du coup à l’usage (et c’est ce qui est important), que cette particularité soit caché par une interface qui te permet d’apply le stash qui est au milieu de la pile, franchement osef. C’est même bien plus pratique.

artragis

Hein ? Je sais pas comment tu bosses, mais des stash avec plus que mettons 5 éléments, ça m’est jamais arrivé, et la plupart du temps juste savoir que c’est un FILO me permet de bosser avec le stash de mémoire sans avoir besoin de chercher quoique ce soit. Pas besoin d’alias ou je ne sais quoi pour manipuler la pile en question d’ailleurs…

Je me demande si des gens qui utilisent Git se servent vraiment de la staging area, oui. Parce que je me suis rendu compte que depuis que j’utilise un client qui ne l’intègre pas, elle me manque tellement peu que je ne sais même plus ce que j’en faisait avant !

Ma réponse est similaire à celle de @Stranger, je m’en sers quasiment à chaque commit non trivial comme brouillon de commit. La plupart de mes codes sont assez techniques, donc par exemple je stage les morceaux de codes sur lesquels j’ai déjà revérifié les équations.

Édité par adri1

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0

Merci @Stranger et @adri1 . Est-ce que vous utilisez un éditeur qui gère l’historique local ? Si oui, ça ne fait pas doublon ?

Personnellement je me sers massivement de l’historique local d’IntelliJ (sur lequel on peut coller des étiquettes), et le cas échéant je commite / modifie mes commits (j’ai tendance à beaucoup modifier mon arbre de commits avant push, vu que c’est très facile pour s’y retrouver, même en ayant plusieurs branches de travail pour tester des trucs).

Est-ce que vous utilisez un éditeur qui gère l’historique local ? Si oui, ça ne fait pas doublon ?

Je suis pas sûr de comprendre ta question. En fait, si j’utilise la staging area, c’est justement pour ne pas avoir besoin de retoucher mes commits après coup. Ou alors j’y vais à coup de rebase interactif et de commit --amend en ligne de commande. J’ai tellement peu le cas d’usage en fait que c’est pas un problème qui se pose pour moi.

Si par "historique local" tu entends celui de l’éditeur lui-même et pas des commits non pushés, c’est juste pas assez pratique par rapport à la staging area quand les changements s’étalent sur plein de fichiers et ne sont pas chronologiques. Avec la staging area, tu découples pas mal la partie codage et le commit lui-même. J’utilise Vim aussi que j’ouvre et ferme sans arrêt, avec des buffers dans tous les sens et potentiellement plusieurs instances, donc peut être que ce que fait IntelliJ remplace bien mon propre worflow mais n’est pas applicable à mon cas.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+1 -0

En plus du cas présenté pour la staging area, je l’utilise aussi beaucoup quand je réécris des commits, à coup de add -p et reset -p. C’est bien pratique d’avoir des modifications en cours sur les fichiers qui ne seront pas intégrées au prochain commit.

J’ai une question que j’ai jamais osé poser (maintenant que vous avez parlés de choses intéressantes) … Et les hooks ? En tant que bon petit développeur (merci ZdS pour ça, d’ailleurs), j’ai mis un commit hook pour faire passer l’ami flake8 avant commit, afin d’éviter les problèmes. Problème, j’ai mis ça dans mon virtualenv, et j’appelle la commande directement: en CLI, je suis dans mon virtualenv, donc pas de problème. Via PyCharm, forcément, no such file or directory. Est ce qu’il y a plus intelligent que:

  • Mettre le chemin vers le flake8 situé dans le bin du virtualenv, ou
  • Installer flake8 globalement (ce qui, normalement, ne pose pas trop de problème pour flake8, à moins qu’on ne change les règles du jour au lendemain, mais imaginons que ce soit une autre commande beaucoup plus obscure, ça pourrait être le cas)

… Parce que je vous avoue que c’est toujours ça qui m’a empêché d’utiliser une GUI (oui, c’est idiot).

Édité par pierre_24

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

Mettre le chemin vers le flake8 situé dans le bin du virtualenv

Dans les faits il est fortement conseillé, quand on utilise la CLI avec python de faire /chemin/vers/python -m commande plutôt que commande. Donc dans notre cas /chemin/vers/venv/bin/python -m flake8.

+0 -0

Concernant git stash je me souviens qu’en tant que jeune ignorant, je l’utilisais souvent dès que git pull n’était pas content si je me souviens bien. Après j’ai compris ma mauvaise pratique (entre autre car je ne faisais jamais de pop de ce que j’avais stashé).

Récemment, je me suis mis à avoir une utilisation de stash et c’est bien la première fois en quelques années. Je ne dis pas que c’est la meilleure façon de faire mais c’est la meilleure solution que j’ai trouvée.

On est deux collègues qui travaillent sur deux branches mais ma branche était basée sur la sienne. Il se trouve que dans l’entreprise, notre workflow est basé sur rebase et donc très souvent on réécrit l’historique en local (on a jamais de commit de merge). Pour je ne sais plus qu’elle raison j’avais besoin de pull les derniers changements de mon collègue alors que je n’avais pas fini de faire ce que je voulais.

Du coup j’ai stash mes changements, fait un rebase et j’ai pop, et c’était magique.

Concernant le débat CLI/GUI, j’utilise une sorte d’hybride qui s’appelle magit et qui est intégré à emacs. Ce n’est pas vraiment une GUI car il n’y a rien de graphique, c’est juste du texte mais c’est super bien présenté et avec pleins de raccourcis pratiques. Il ne me viendrait pas à l’idée de faire un rebase intéractif en CLI maintenant. Du coup même si m’a compréhension de Git s’est amélioré au fil du temps, j’utilise magit depuis 4 mois et je réalise aujourd’hui que j’aurais beaucoup de mal à revenir à la CLI.

+1 -0

Par rapport à Saroupille, j’ajouterais que magit, en plus de donner un raccourci en une touche pour faire une action, montre aussi à côté quelle est la commande (ou sous-commande) correspondante. Donc en l’utilisant, on va plus vite qu’en utilisant la CLI mais on s’habitue aussi aux commandes "vanilla" de la CLI et le savoir est facilement transposable.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte