Journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
20
14
sept.
2016

Bonjour,

On n'en a pas beaucoup parlé ici, mais ça fait maintenant un peu plus d'un an que la communauté de développeur de Git a sa lettre mensuelle : Git Rev News.

L'édition #19 vient de paraître : https://git.github.io/rev_news/2016/09/14/edition-19/.

Au programme : une présentation de l'outil git series, un bilan rapide du Google summer of code, un appel à contributeur pour Git Rev News, une interview du contributeur Brian M. Carlson, et comme chaque mois, un paquet de liens récoltés sur le web à propos de Git et des outils connexes.

Plus d'infos sur Git Rev News, les archives, l'URL à donner à manger à votre lecteur RSS, … ici : https://git.github.io/rev_news/rev_news/.

J'en profite pour attirer votre attention sur le sondage pour utilisateurs de Git, ressuscité après plusieurs années d'absence. C'est un bon outil pour avoir une idée de ce que les utilisateurs font avec Git, mais une précondition pour qu'il soit intéressant est qu'il y ait beaucoup de participants, d'un maximum de provenances différentes.

Si vous pouvez prendre quelques minutes pour y répondre, c'est par ici : https://survs.com/survey/s2s3t4l8jb (suivre de préférence ce lien, généré spécifiquement pour linuxfr).

  • # rss?

    Posté par  (site web personnel) . Évalué à 2.

    Plus d'infos sur Git Rev News, les archives, l'URL à donner à manger à votre lecteur RSS, … ici : https://git.github.io/rev_news/rev_news/.

    C'est une page HTML.

    blog.rom1v.com

  • # Rrrr Zzzz

    Posté par  . Évalué à 10.

    Si vous pouvez prendre quelques minutes pour y répondre

    Je l'ai fait, mais qu'est-ce qu'il est chiant ce sondage… Des listes de zillions d'outils dont personne n'a jamais entendu parler, des dizaines et des dizaines de questions… et pas une pour demander par exemple quelles opérations on comprend/maitrise (perso, à part commit, branch, checkout, pull et push, il faut que je copie-colle les tutoriels…). Du coup, j'ai l'impression que le projet git n'a pas tellement l'intention de faciliter la prise en main de l'outil…

    • [^] # Sondage bien pensé globalement sans être chiant à compléter

      Posté par  (site web personnel) . Évalué à 4.

      Je suis d’accord que les points que tu soulèves sont chiants. Mais, je trouve que le sondage est globalement bien pensé sans être chiant à compléter.

    • [^] # Re: Rrrr Zzzz

      Posté par  (site web personnel) . Évalué à 8.

      Je n'ai pas eu de temps à consacrer à la préparation du sondage (donc dur de critiquer), mais je suis partiellement d'accord avec toi : le sondage est très orienté « que faites-vous avec Git ? » (qui est super important pour les développeurs) mais très peu sur les difficultés d'apprentissages (qui le seraient aussi).

      Ceci dit, il ne faut pas en conclure qu'il n'y a pas d'effort pour rendre le logiciel plus facile à prendre en main. Si tu regardes l'évolution de l'outil, il y a des tas de petites choses qui ont été changées pour aider les débutants, et ça continue. Je donne des cours sur Git à des débutants complets, et les points sur lesquels j'avais toujours les mêmes questions il y a quelques années ont à peu près tous été réglés (ça n'est pas une coïncidence, en général c'est moi qui ai envoyé les patchs ;-) ). Y'a encore du boulot, mais ça avance.

      • [^] # Re: Rrrr Zzzz

        Posté par  (site web personnel) . Évalué à -1.

        git est quand même très chiant à utiliser par rapport à SVN dans un environnement avec qq développeurs.

        Tu passes ton temps à savoir si faut faire commit, stash, rebase, push. Tout ça pour faire l'équivalent d'un commit SVN.

        git permet de faire des millions de choses. Mais si tu respectes qq règles, comme un seul repository central, une historique propre (rebase et non merge tout le temps), tu n'as pas 50 façons de faire. Mais la façon propre est chiante. Et à la moindre erreur tu peux tout casser. Changer l'historique est sympa (rebase), mais l'historique n'est pas historisé, donc tu ne peux pas facilement revenir en arrière parfois.

        "La première sécurité est la liberté"

        • [^] # Re: Rrrr Zzzz

          Posté par  . Évalué à 5.

          Je suis très loin d'être un spécialiste…

          Tu passes ton temps à savoir si faut faire commit, stash, rebase, push. Tout ça pour faire l'équivalent d'un commit SVN.

          J'ai pas l'impression de galérer avec ça.

          rebase et non merge tout le temps

          Hum… En principe je fais un rebase de ma branche vers le master (donc ma branche est à jour du master), puis un rebase -i pour réécrire l'historique comme je veux, puis depuis le master je merge ma branche. Sa sérialise l'historique oui, mais globalement je me fous de savoir qu'il y avait une branche et mon serveur est un SVN (sic) donc je ne suis même pas sûr de ce que ça donnerait comme historique autrement.

          D'ailleurs même avec du git sur serveur, pour ne pas se servir de merge, ça veut dire que tu garde toutes tes branches sur le serveur (git refuse de supprimer les branches non mergées de base) ? Ou il y a quelque chose pour « fermer une branche », juste histoire de ne pas avoir plusieurs millier d'entrée quand tu fais un fetch -a par exemple.

          […] mais l'historique n'est pas historisé, donc tu ne peux pas facilement revenir en arrière parfois.

          Quand je maîtrisais encore moins qu'aujourd'hui, j'utilisais format-patch pour garder une ancienne version de l'historique en locale. Mais tu peux le faire avec des branches locales de backup (ou archiver ton dépôt avec un tar -). Je trouve le fait de travailler en local très rassurant au contraire.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Rrrr Zzzz

            Posté par  (site web personnel) . Évalué à 1.

            "J'ai pas l'impression de galérer avec ça."

            Le truc, c'est qu'il faut 4 commandes au lieu d'une. J'imagine qu'il faudra attendre un outil qui masque cette complexité en forçant une manière de faire.

            "La première sécurité est la liberté"

            • [^] # Re: Rrrr Zzzz

              Posté par  . Évalué à 10.

              Le truc, c'est qu'il faut 4 commandes au lieu d'une.

              Euh… Elles ont toutes un sens propre. Je veux dire, personnellement, je n'ai pas de séquence de 2 ou 3 commandes que je lance systématiquement ensemble. J'aurais tendance à dire que travailler vraiment comme SVN (avec des commits réseau par exemple) perds beaucoup de l'intérêt de l'outil.

              J'imagine qu'il faudra attendre un outil qui masque cette complexité en forçant une manière de faire.

              Ou simplement te créer les alias git qui vont bien par exemple (écris à l'arrache

              [alias]
  svncommit = !git commit -a && git push
  svncheckout = !git stash && git pull && git stash apply && git stash clear

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Rrrr Zzzz

                Posté par  (site web personnel) . Évalué à 2.

                [alias]
                svncommit = !git commit -a && git push
                svncheckout = !git stash && git pull && git stash apply && git stash clear

                Ben non. ton svn commit ne marche pas si ton origin a avancé, il faut un rebase avant. Et bien sur tu choisi tes fichiers

                ton svcheckout, tu ne veut pas de git pull, mais un rebase, pour éviter des merges inutiles, si tu as fait des commit avant.

                En tout cas, je ne connaissais pas les alias.

                "La première sécurité est la liberté"

                • [^] # Re: Rrrr Zzzz

                  Posté par  . Évalué à 4.

                  Ben non. ton svn commit ne marche pas si ton origin a avancé, il faut un rebase avant. Et bien sur tu choisi tes fichiers
                  ton svcheckout, tu ne veut pas de git pull, mais un rebase, pour éviter des merges inutiles, si tu as fait des commit avant.

                  Comme je disais ils sont écris à l'arrache :)

                  En tout cas, je ne connaissais pas les alias.

                  Content d'avoir était utile alors, c'est assez pratique d'autant qu'ils sont pris en compte par l'autocomplétion.

                  J'en abuse pas, mais j'apprécie énormément de pouvoir avoir :

                  lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

                  Tu pourra trouver pleins d'exemple de log amélioré sur internet (le miens n'est pas de moi d'ailleurs) et pouvoir avoir un commit par ligne en couleur etc c'est le pied :)

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Rrrr Zzzz

                  Posté par  (site web personnel) . Évalué à 2.

                  [alias]
                  svncommit = !git commit -a && git push

                  Ben non. ton svn commit ne marche pas si ton origin a avancé, il faut un rebase > avant.

                  Tout pareil qu'avec SVN, non ? Quand ton checkout n'est pas à jour, il faut faire un update (la dernière fois que j'ai essayé SVN le message d'erreur était « out of date in transaction », sans l'ombre d'une suggestion de comment sortir de la situation, qui fait un peu rire jaune pour un outil orienté convivialité et simplicité d'ailleurs).

                  Mais bon, l'intérêt de Git est quand même de pouvoir commiter plusieurs fois avant de faire un push justement. Et clairement l'interface en ligne de commande de Git est optimisée pour ça.

                  svncheckout = !git stash && git pull && git stash apply && git stash clear

                  Ou git pull --rebase --autostash. Ou alors on configure les variables qui vont bien et ça s'appelle juste git pull.

                  • [^] # Re: Rrrr Zzzz

                    Posté par  . Évalué à 8.

                    Tout pareil qu'avec SVN, non ? Quand ton checkout n'est pas à jour, il faut faire un update

                    Je ne crois pas non. La grosse différence avec SVN c'est qu'avec ce dernier, tu n'es pas empêché de committer si les changesets portent sur des fichiers disjoints. Avec git et tous les DVCS, c'est le cas. C'est inhérent au modèle distribué. Ces fameux commits de merge que l'on se doit de filtrer pour rendre l'historique plus clair ou qui justifient l'existence du rebase.
                    Ceci peut paraître anodin mais ça a une conséquence importante:
                    Avec SVN la gestion des composants est beaucoup plus souple. Un repo SVN peut accueillir des modules disjoints et les gérer comme des projets séparés de manière transparente. On n'est pas pollué par les commits des autres tout en bossant avec du trunk dev. Ceci offre beaucoup de souplesse pour faire évoluer son architecture. A un moment, on peut incorporer du code d'un autre composant ou au contraire le séparer … sans perdre l'historique.

                    Avec git, il faut faire des choix à priori en séparant les composants et utiliser les submodules (ou d’autres solutions équivalentes) avec toute leurs limitations et des problèmes à gérer si ces choix s’avéraient erronés ou si les besoins évoluent. L'autre solution est de dédier une branche par composant avec toute la complexité associée (convention de nommage sur les branches, …).
                    Je conviens que ceci est assez largement compensé par le fait que la gestion par composant peut se faire au niveau binaire, mais la granularité d'un article de configuration n'a jamais été chose simple et quelquefois la gestion de composants niveau source est incontournable.

                    J'ai eu à traiter une migration SVN d'un projets qui hébergeait des services. Ce fut un véritable casse-tête.
                    Pas convaincu ? Alors lisez pourquoi Google assume ce choix
                    http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

                    « out of date in transaction », sans l'ombre d'une suggestion de comment sortir de la situation,

                    Grosse mauvaise foi détectée.
                    J'ai moi aussi l'occasion d'enseigner git à « quelques » novices et même si je n'ai certainement pas tes compétences sur les entrailles du bousin, n'étant pas contributeur sur le projet, je trouve quand même ta remarque assez décalée lorsqu’il faut expliquer pourquoi on se prend un "push rejected: non-fast-forward". C'est assez cocasse d'ailleurs que pour dépatouiller tu confesses d'être obligé de faire appel à ton expertise. Ca prouve la simplicité du bousin. Pour alimenter la réflexion et sans attaque personnelle, voici un article (https://medium.com/@cscalfani/why-experts-make-bad-teachers-ccaed2df029b#.luyizwowj) qui amène à se questionner sur la manière de transmettre son savoir en tant qu’expert d’un domaine
                    Au titre des choses amusantes aussi, les milles manières de réécrire un historique en multipliant les commandes (rebabse -i, squash, amend, cherry-pick, reset --soft|mixed, …) mais expliquer après que par contre, ils n’ont pas été foutu de séparer le checkout d'un commit et d'un fichier, en 2 commandes distinctes ou de s'accorder sur un nom de commande pour cleaner l'index et qu'il faut en passer par un reset HEAD tellement evident … qu’un bookmark stack overflow de + pour votre collection http://stackoverflow.com/questions/19730565/how-to-remove-files-from-git-staging-area) avec un alias à la clé.

                    Autre truc amusant, les explications sur les dangers des commandes qui réécrivent l’historique et qu’il faut utiliser avec précaution (amend, reset , …) à cause des push. Alors oui, il y a le --force qui prévient. Oui comme tu l’expliques ailleurs, la force de Git c’est la gestion de son historique local et il faut expliquer au newbies qu’une branche locale c’est un peu comme son workspace git, c’est un espace privé. Mais en centralisé, il y a fallu créer des webhooks ou positionner des options git pour bloquer les conneries. Et on aimerait bien que git soit un peu plus prévenant en amont; comme par exemple des options pour limiter le reset sur commits non pushés. Evidemment ce n’est pas possible puisque git de base doit aussi supporter le mode décentralisé et que dans ce cas rien ne peut être anticipé (je ne sais pas qui a déjà cloné ma branche si je bouge ma ref).

                    Mais dans tout ça, ce que je trouve le plus savoureux, c'est de me remémorer ces trolls où certains disaient que le fait que git récupère une copie du dépôt en entier était un problème. Surtout pour un workflow centralisé en entreprise, ça n'était pas forcément un choix pertinent. On nous expliquait que grâce à son algo de compression ce n'était absolument pas un problème pour le transfert que le kernel en était une preuve.
                    Et maintenant, on prend conscience que des projets, ce ne sont pas que des fichiers source mais qu'on a besoin de jeu de données pour les test d'intégration, de stocker des binaires notamment dans le domaine du jeu (artworks) … et que leur place est bien dans le dépôt. Ce ne sont pas des documents Word avec lesquels on explique gentiment qu'il y a d'outres outils pour ça.

                    Moralité depuis:
                    * J'ai un collègue admin qui fait la chasse aux binaires dans les dépôts et s'amuse à les cleaner à coup de bfg (comment ça l'historique d'un projet est sacré ma bonne dame ? … Vous ne vous en servez plus, raison de service, Léon le nettoyeur va passer). En terme d’admin, on se croirait revenu au temps glorieux de Clearcase, tient.
                    * Git prend en charge le fait de partager un même dépôt entre plusieurs workspaces alors qu'on se moquait doucement des DVCS qui le permettaient. (Je conviens que c'est vraiment un nice to have parce qu'une recopie d'un clone en local ça coûte rien en réseau)
                    * Git étant surtout utilisé en centralisé (merci Github et Atlassian) et v'la tit pas qu'on nous sort du git LFS pour adresser le problème des gros fichiers. Quelle ironie du sort. A chaque checkout, on va vous expliquer qu'il faut être connecté pour récupérer la bonne version du binaire. Allez encore un petit effort et vous allez découvrir la notion de client serveur, de workspace en mode centralisé et qu'un cache pour stocker l'historique, c'est suffisant (Perforce le gère depuis le début). Ok je retire cette dernière phrase qui est de la pure provoc.

                    L'autre gros soucis dans le cas de workflow centralisé concerne le lock pessimiste. On a beau nous expliquer qu'un outil de gestion de version n'a pas vocation à être un outil de communication, l’argument ne passe pas. Expliquez-moi ce dont vous avez besoin, on vous expliquera comment vous en passer ! (Petit hommage à Coluche, tu nous manques). Lorsqu'on bosse avec des fichiers binaires comme des images, des fichiers qui ne proposent pas leur propre interface de merge (modèle UML, fichiers XML persistants avec une sémantique bien définies), l'argument a du mal à passer et les options --ours et --theirs du merger sont quand même un peu légères. Lorsque tu viens de te chiader l'édition d'une image et qu'un gugusse te balance une modif en même temps, y’a quand même un souci et si on vous rétorque que vous avez qu’à vous parler avant, vous pouvez aussi lui renvoyer que dans ce cas les merges ne servent à rien sur les fichiers source et il suffit de se parler et de revenir à ce bon vieux RCS. SVN avec les properties sur les types de fichiers et le svn lock le suporte au poil. Autre exemple, Talend studio (un ETL) a récemment migré de SVN vers Git pour son studio, suite forte pression client. Ils se sont retrouvés à réécrire un système de lock à part du cvs parce que les mêmes clients ne veulent pas sacrifier sur le lock pessimiste non plus.

                    Aujourd'hui le bilan est le suivant. Malgré ces mérites indéniables (on est tous d’accord), on se retrouve coincé avec un outil dont la vocation n'est pas le modèle centralisé. On nous explique qu'il le gère, car qui peut le plus peut le moins. Mais du coup des choses basiques qui pourraient améliorer ce workflow seraient incompatibles avec les autres modèles de workflow. Alors on voit émerger de plus en plus de solutions de contournement. Soit, mais s'il vous plait, convenez que SVN est assez adapté pour ce besoin et non, git de base n'est pas toujours aussi adéquat ni en termes de simplicité ni en termes de besoins. A côté de ça, personne ne souhaite revenir sur le confort de rajouter un remote pour bosser sur le même projet entre 2 organisations séparées ou encore la possibilité d'accueillir des contributions ponctuelles avec des pull request mais on est bien au delà d'un simple projet centralisé dans une entreprise. Quand à la possibilité de réécrire son historique avant de pusher, top de choix tue le choix. Pas toujours facile de s'accorder sur la bonne granularité du commit. Entre ceux qui visent la simplicité et veulent pouvoir cherry-picker un seul commit pour reporter une feature, ceux qui veulent pouvoir relire l'historique par petits incréments et trouvent que c'est plus simple en cas de rebase, les protagonistes de la feature branch.
                    Et voilà encore un nouvel animal de foire, le git series … Si ce n'est pas du cargo cult, en tout cas ça y ressemble parfois.
                    Pas facile de faire comprendre un newbie qui vient de découvrir les branches, les pull request vendues par les marchands de rêves à la Github/Bitbucket et qu'il veut vous en fourguer partout, que ça contrevient un des principes de bases de l'agilité: l'intégration continue. quPas facile de lui faire comprendre que les features branches n'ont rien d'agile (http://martinfowler.com/bliki/FeatureBranch.html) et venir le voir pleurer lorsqu'il a refactoré comme un porc et se trouve comme un con avec un big bang merge et qu'on doit se taper de le dépanner à coup de stratégies de merge et d'ajustement du "threshold" dans le find-renames.

                    Avec de grands pouvoirs, viennent de grandes responsabilités…

                    • [^] # Re: Rrrr Zzzz

                      Posté par  (site web personnel) . Évalué à 3.

                      out of date in transaction », sans l'ombre d'une suggestion de comment sortir de la situation,

                      Grosse mauvaise foi détectée.
                      J'ai moi aussi l'occasion d'enseigner git à « quelques » novices et même si je
                      n'ai certainement pas tes compétences sur les entrailles du bousin, n'étant pas
                      contributeur sur le projet, je trouve quand même ta remarque assez décalée
                      lorsqu’il faut expliquer pourquoi on se prend un "push rejected: non-fast-forward".

                      Avec SVN :

                      Sending        foo.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File '/tmp/checkout/foo.txt' is out of date
svn: E160028: File '/foo.txt' is out of date

                      Avec Git :

                      To /tmp/git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to '/tmp/git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

                      Désolé, je suis sincère quand je dis que je trouve le second plus facile à comprendre. Après, avec les débutants mon plus gros problème est que le message de Git est plus long donc les étudiants s'arrêtent au milieu (et l'incitation à lire la doc est vue comme limite injurieuse !), mais bon …

                      • [^] # Re: Rrrr Zzzz

                        Posté par  (site web personnel) . Évalué à 3.

                        Sauf que ton message avec SVN n'arrive quasiment jamais, alors que le 2nd de git est systèmatique. Car l'un à la granularité du dépot, l'autre des fichiers.

                        "La première sécurité est la liberté"

                        • [^] # Re: Rrrr Zzzz

                          Posté par  . Évalué à 3.

                          Car l'un à la granularité du dépot, l'autre des fichiers.

                          De la branche plus exactement.
                          C'est la raison pour laquelle j'expliquais que dans une migration git avec plusieurs composants (/comp1/trunk, /comp1/v.1.x, /comp2/trunk, …), une des solutions est de créer des branches équivalentes.
                          Ainsi, tu n'es pas pollué par les commits dans les autres branches, y compris celles des autres composants.

                          Et par ailleurs, la granularité de SVN pour un commit est par contre le dépôt (une révision par depôt). Mais grâce au fameux buble-up, il est capable de commiter des fichiers qui n'entrent pas en conflit, et tout ça de manière transactionnelle (contrairement à ce bon vieux CVS).

        • [^] # Re: Rrrr Zzzz

          Posté par  . Évalué à 4.

          Changer l'historique est sympa (rebase), mais l'historique n'est pas historisé, donc tu ne peux pas facilement revenir en arrière parfois.

          Il l'est ! Regarde du côté de git reflog ou en utilisant git log --all --graph --reflog :)

          bépo powered

          • [^] # Re: Rrrr Zzzz

            Posté par  . Évalué à 2.

            Et du coup maintenant il l’est de manière permanente et plus robuste avec le nouveau git-series dont parle le journal.

        • [^] # Re: Rrrr Zzzz

          Posté par  (site web personnel) . Évalué à 5.

          Mais la façon propre est chiante. Et à la moindre erreur tu peux tout casser.

          Mon expérience est exactement l'inverse. J'ai enseigné SVN à des débutants, ils galéraient tous sur des conneries (beaucoup ont été résolues depuis, mais par exemple un svn update était capable de mettre à jour la moitié d'un arbre de travail, s'arrêter sur une erreur du style ! nom-de-fichier.txt et s'arrêter là en laissant tout en vrac, et bon courage pour comprendre ce que ! veut dire), et quand j'essayais de les dépanner ils avaient réussi à mettre une grouille pas possible et je ne pouvais rien faire d'autre qu'un nouveau checkout.

          Avec le passage à Git, j'ai beaucoup moins de questions, et infiniment moins d'étudiants qui jettent l'éponge en me disant « monsieur, Git est cassé ». Et quand je dois dépanner quelqu'un qui a mis le bronx dans son dépôt Git, au moins, je sais comment faire : git status dit des trucs pertinents, l'historique est historisé et il y a plein de gardes fous dans Git qui ne sont pas dans SVN pour éviter de perdre des données.

          On est loin de l'outil idéal, mais face à des débutants complets qui ne connaissent pas SVN, ça ne se passe pas si mal que ça.

          Après, que Git soit très pénible à pendre en main quand on a ses habitudes sous SVN, je crois que personne ne le conteste.

          • [^] # Re: Rrrr Zzzz

            Posté par  (site web personnel) . Évalué à 3.

            Parce que avec les étudiants, si chacun est avec son dépot, cela n'a rien à avoir avec 5 dev, qui développe sur 5 dépôts à la fois.

            "Après, que Git soit très pénible à pendre en main quand on a ses habitudes sous SVN, je crois que personne ne le conteste."

            Non, cela n'a rien à avoir avec ça. Git est rapide et permet plein de choses, mais une fois que l'on a choisi un mode de dev précis (une seul branche commune), il faut respecter un tas de commande pour ne pas tout foutre en l'air. Alors oui, on peut faire des aliais. Mais il n'y a pas 50 façons de faire du dev avec git, il faudrait juste 3 ou 4 set de commande en fonction de la méthode choisie.

            "La première sécurité est la liberté"

            • [^] # Re: Rrrr Zzzz

              Posté par  . Évalué à 4.

              Mais il n'y a pas 50 façons de faire du dev avec git, il faudrait juste 3 ou 4 set de commande en fonction de la méthode choisie.

              AMHA il y en a plus. Il est tout à fait possible de créer un gitflow-like pour ton workflow. gitflow a précisément était créé pour ça : simplifier une méthode de développement.

              Je pense que c'est une bonne chose d'avoir un outil agnostique puis d'avoir des plugins/surcouche « opinionated » comme disent les anglosaxons.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Rrrr Zzzz

                Posté par  (site web personnel) . Évalué à 2.

                C'est ce que je disais par 3 ou 4 manières de faire.

                Mais typiquement gitflow ne semble pas satisfaisant.

                Il faudrait que "El Titi ✏" propose son propre set d'alias Git qui suit sa proposition de flow. C'est déjà un bon début, avant de faire un outil complet.

                "La première sécurité est la liberté"

                • [^] # Re: Rrrr Zzzz

                  Posté par  . Évalué à 4. Dernière modification le 20 septembre 2016 à 21:35.

                  Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.
                  Nous proposons 2 workflows dans ma boîte car 2 méthodes de projets coexistent (Une itérative à la RUP et une agile basée sur SCRUM).
                  Ils ne sont pas outillés car le but est de ne pas proposer de choses trop compliquées.

                  Notre workflow agile est très semblable à ce qui est proposé ici :
                  http://endoflineblog.com/gitflow-considered-harmful
                  http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
                  (Le 2ème post apporte des précisions utiles)

                  Les seules adaptations concernent:
                  1. Le suivi de la version en prod. On la marque par un tag qu'on déplace plutôt que par une branche
                  2. Les features branch:
                  Autant que faire se peut, on les décourage, mais à ceux qui souhaitent vraiment les mettre en oeuvre, on donne quelques consignes:
                  Qu'elles soient courtes et rebasées y compris sur le serveur de CI (elle sont propres à un seul developpeur). Le workflow ressemble alors à ce que décrit par Crev ici (rebase, push --force, revue éventuelle, merge --no-ff)
                  S'il s'agit d'epic et que l'on veut vraiment l'isoler dans une branche, il ne faut qu'il y en ait qu'une seule, que l'on réintègre depuis master à chaque commit (merge auto en CI qui casse le build si pb).

                  Sinon, si tu veux vraiment retrouver ton workflow à la SVN, hormis les 2 commandes de nos compères:

                  [alias]
  publish = !git commit --all  && git push
  update = !git pull --rebase --autostash

                  Je verrais bien une commande intermédiaire qui te permet d'enregistrer ton travail en local régulièrement:

                  [alias]
  record = !git commit -all
  overwrite = !git commit -all --amend

                  et une pour le resolve après un update:

                  [alias]
  record = !git add

                  • [^] # Re: Rrrr Zzzz

                    Posté par  (site web personnel) . Évalué à 2.

                    En fait, je pensais plus que tu proposerais une série d'alias précis qui correspond à différentes étapes de ton propre flow. Comme je dis plus haut, les "alias svn" ne fonctionne pas bien. Ton publish doit comporter un git rebase, avant le push, pour gérer le cas d'un push d'un autre dev. "update" doit faire un fast-forward, sinon cela entraîne un merge qui pourris l'historique.

                    Il faudrait trouver des alias qui fonctionnent dans tout les cas, et qui suit un flow précis que tu recommandes.

                    "La première sécurité est la liberté"

                    • [^] # Re: Rrrr Zzzz

                      Posté par  . Évalué à 3.

                      "update" doit faire un fast-forward, sinon cela entraîne un merge qui pourris l'historique.

                      L'option --rebase t'évite un merge. Par contre, en cas de conflit, tu es interrompu au milieu de ton rebase.
                      Du coup, il vaudrait mieux squasher avant:

                      update = !git squash & git pull --rebase --autostash

                      Ton publish doit comporter un git rebase, avant le push,

                      Avec svn si tu es empêché de commiter tu updates. Tu n'updates pas avant. Je suppose que tu veux rebaser pour les fichiers disjoints et échouer s'il y a un conflit.
                      IJe n'ai pas vu d'option de rebase qui le permettrait.

                      En fait, je pensais plus que tu proposerais une série d'alias précis qui correspond à différentes étapes de ton propre flow.
                      Je pourrais présenter les commandes enchainées. Mais l'intérêt de l'outiller me parait superflu étant donné qu'il est finalement assez simple.

                      • [^] # Re: Rrrr Zzzz

                        Posté par  (site web personnel) . Évalué à 2.

                        Mais l'intérêt de l'outiller me parait superflu étant donné qu'il est finalement assez simple.

                        L'avantage des alias est de dire, quand utiliser quoi. C'est tellement facile d'oublier une option et tout foutre en l'air.

                        J'ai déjà bosser sur dépot distant git qui était une copie d'un dépot de logiciel libre. Parfois, on devait faire un rebase de ce dépot. Impossible de trouver la commande pour remettre d'aplomb mon dépôt perso, il fallait refaire un clone.

                        "La première sécurité est la liberté"

                  • [^] # Re: Rrrr Zzzz

                    Posté par  . Évalué à 4.

                    Je réfléchis à cette proposition et si ça intéresse quelqu'un j'envisage une série de journaux pour présenter différents workflows avec les tenants et aboutissants de ces choix.

                    Ce serait super intéressant ! :)

                    Je verrais bien une commande intermédiaire qui te permet d'enregistrer ton travail en local régulièrement:

                    [alias]
  record = !git commit -all
  overwrite = !git commit -all --amend

                    et une pour le resolve après un update:

                    [alias]
  record = !git add

                    En fait pour ce genre d'alias tu peut simplement faire :

                    [alias]
  record = commit -all
  overwrite = commit -all --amend
  record = add

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Workflow git

    Posté par  . Évalué à 3.

    On utilise git avec git-flow au boulot (les commandes de flow en détail). Cela nous permet de simplifier les interactions entre les différentes branches. Les hotfix nous font gagner pas mal de temps. Le lancement de release est facile à gérer entre plusieurs développeurs tout en continuant à intégrer de nouvelle fonctionnalité sur la branche de dev.

    Pour récupérer les derniers changement sur l'origine, une configuration globale de git pour faire un git pull --rebase par défaut.

    Je trouve l'utilisation de git beaucoup plus simple qu'avec SVN. On a eu énormément de problème avec les branches sur SVN au boulot (je ne serais plus dire exactement, c'était un il y 2 ans). Sûrement que l'outil est mieux adapté à nos problématiques.

    • [^] # Re: Workflow git

      Posté par  . Évalué à 7. Dernière modification le 17 septembre 2016 à 18:47.

      Ah ce fameux git-flow. Il y a tant à dire.

      J'espère que vous ne bossez pas en agilité dans ta boite ? Auquel cas, ce message ne te concerne pas.

      Déjà cette drôle d'idée de reporter toutes les versions de prod sur la branche master et de dédier develop à ça.
      Quand un gars arrive dans une équipe pour se joindre aux forces vives, quoi de plus naturel que de bosser dans master. Si je veux connaitre le version de prod, y'a quoi de compliqué de s'appuyer sur une convention de nommage et de lister les tags avec un petit grep des familles.

      Ensuite cette manie de créer une branche de release pour la recette et la maintenance. En agilité que ce soit en scrum, kanban, lean ou à fortiori en continuous deployment, on a coutume de réintégrer les demandes de corrections plus tard (sprint suivants). On ne s'amuse pas relivrer des corrections en recette ou en prod sauf cas du hotfix qui est le seul qui nécessite une branche dédié à réintégrer dans la master. Evidemment on automatise un max avec une batterie de test pour qu'une recette ne dure une éternité (test exploratoires). La branche de release avec un environnement stable pour tester est le signe avant coureur que le projet va partir en couille et que les prestataire de monkey tester vont débarquer en masse. Le cône glacé va vous refroidir.

      Enfin les feature branch. Le jour où on comprendra que développer à base de feature branche, et pour aller encore plus loin de pull request avec revue online comme veulent absolument nous les refiler Atlassian, Github, Gitlab et consors qui ont tout intérêt a centraliser encore plus les workflowws autour de leurs outils pour nous revendre leur bidules, on aura fait de grands progrès.
      L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu. Relisez c'est article de Martin Fowler pour comprendre pourquoi c'est le mal:
      (Je l'ai déjà posté plus haut mais là je vais appuyer l'argumentaire). Dans une feature branch,vous retardez l'intégration de vos devs et par delà la découverte de problèmes d'architecture. Vous pouvez vous réalignez régulièrement par rapport à master (merge from upstream) mais il n'en reste pas moins que vous êtes isolés de toutes les features pas encore intégrées et les autres de la vôtre. Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment… peu avant la fin du sprint.
      Certains parlent alors du mini effet tunnel qui vous fait retomber dans les travers des méthodes traditionnelles, consustant à tout intégrer dans l'urgence et souvent au détriment de la qualité (on n'a pas le temps de refactorer nos tests là, on est à la bourre).

      Au fait, reposons-nous la question: Quelle sont les raisons pour lesquelles on souhaiterait mettre en place des feature branch?
      La réponse qui vient immédiatement concerne la souplesse que ça nous apporte. On peut décider d'intégrer une feature au moment d'une livraison ou de la reporter si elle n'est pas prête.
      Alors déjà, première chose: Pourquoi passer systématiquement par une branche surtout en début de sprint ?
      Ensuite, quel est le problème de livrer une feature incomplète … si elle n'affecte pas votre produit ?
      Vous voyez poindre la solution qui permet de continuer à développer dans le trunk tout en conservant cette souplesse ? Vous l'avez tous déjà fait un jour. Supprimer un item dans un menu, ou un bouton dans un formulaire…
      Ca s'appelle le feature toggling(http://martinfowler.com/bliki/FeatureToggle.html). Vous structurez votre code pour activer ou non des fonctionnalités au déploiement (http://martinfowler.com/articles/feature-toggles.html).

      Ceci vous permettra même de valider ou non la pertinence d'une fonctionnalité sur un panel de clients précis ou de les comparer en environnement réel. le fameux A/B testing.
      Après, il est vrai qu'une des conséquences est que ça génère de la dette technique, et qu'il faut supprimer le code d'activation lorsque la feature est intégrée ou écartée. Mais il existe des frameworks pour vous y aider.

      Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil … Fuyez !!!

      Toujours pas convaincus ?
      Peut-être que lui y parviendra.

      • [^] # Re: Workflow git

        Posté par  . Évalué à 1.

        Pour votre première question, on ne travaille effectivement pas en agile dans notre boite.

        Je n'ai jamais travaillé en agile et je ne connais donc pas les problématiques qui y sont liées. Votre discours est en tout cas intéressant.

        Dans le cas d'un projet agile en intégration continue, quel type de workflow utilisez-vous ?

        • [^] # Re: Workflow git

          Posté par  . Évalué à 3. Dernière modification le 17 septembre 2016 à 20:41.

          Le plus simple au monde, celui qui reste compatible avec SVN et ses limitations (mais nous utilisons Git, … à bon escient):
          Le Trunk Base Development.
          Une branche pour les gouverner tous.

          Et voici quelques ressources.

          Ponctuellement, une branche de hotfix peut-être nécessaire, mais les protagonistes de Continuous Deployment la proscrivent et privilégient la mise à disposition de correctifs dans le trunk.
          Il est important de dissocier les différents niveaux de maturité en agilité.

          • Le premier est l'intégration continue. Tout est intégré au fil de l'eau
          • Le second est le continuous delivery. On fait en sorte que tout ce qui est intégré soit potentiellement déployable (build au vert et tests automatisés à gogo pour s'assurer de la qualité de la livraison)
          • Le niveau ultime est le continuous deployment. Le déploiement est automatisé lors de chaque build. C'est l’achèvement du DevOps (nous sommes loin de ce niveau de maturité hélas). Wikipedia explique très bien la différence

          Sinon, une autre raison invoquée pour mettre en oeuvre des branches (long-lived) et que je n'avais pas évoquée concerne les migrations techniques.
          On peut-être tenté de créer une branche pour migrer vers un nouveau framework ou toute autre raison technique qui affecte son architecture
          Là aussi ça devient complexe à gérer. Car il faut systématiquement reporter les évolutions livrées dans la branche de prod vers la nouvelle branche de migration technique.
          Une autre stratégie peut-être mise en place. Le "Branching by Abstraction". Ceci consiste à développer une couche d'abstraction dans le trunk puis faire pointer ton architecture dessus, implémenter la nouvelle et basculer dessus. L'avantage c'est que par la force des choses ton architecture devient plus évolutive et par conséquent sa qualité s'améliore (la couche d'abstraction reste).

          Et pour conclure, je cite souvent Martin Fowler. Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile

          • [^] # Re: Workflow git

            Posté par  . Évalué à 3.

            Et pour conclure, je cite souvent Martin Fowler.

            Justement quand je lis son poste « SemanticConflict » que tu as cité et que je lis sa première phrase :

            Those who hear my colleagues and I talk about FeatureBranch know that we're not big fans of that pattern. An important part of our objection is the observation that branching is easy, but merging is hard.

            C'est pour moi exactement l'inverse, si quelque chose est difficile, il faut le faire plus souvent. Si on ne fait pas quelque chose parce qu'elle est difficile, elle restera forcément difficile. Alors que si tu te casse les dents dessus 2, 3, 20 ou 30 fois. Tu va mécaniquement t'améliorer et trouver des solutions pour résoudre tes problèmes.

            Pour le feature branch, il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code (ce que je vois tous les jours) et le feature branche. C'est juste que ce dernier est nommé et est plus correctement outillé. Encore une fois plus ton équipe est petite et mieux ça se passe (les merges peuvent être fait à 2). Personnellement je n'ai jamais trouvé que les merges soient véritablement difficile quand tu n'a pas des gens qui passent des semaines sans faire de merge/rebase.

            Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.

            Au cas où tu émettes quelques doutes sur la crédibilité du personnage, je t'invite à jeter un oeil à la liste des signataires du manifeste agile

            C'est un peu de l'argumentation d'autorité ça ;) M. Fowler est intéressant, mais c'est pas mal d'aller voir ce qui se fait ailleurs (surtout qu'il y a pleins de gens qui parlent de leur expérience sur ce genre de sujets).

            Le niveau ultime est le continuous deployment. Le déploiement est automatisé lors de chaque build. C'est l’achèvement du DevOps (nous sommes loin de ce niveau de maturité hélas).

            C'est surtout pas toujours faisable d'un point de vu non technique (si le déploiement consiste à aller en centrale nucléaire installer ta nouvelle version de logiciel qui met un bout de matos en indispo, pour te cité un cas que je connais et qui est extrême).

            Mais je ne suis pas d'accord sur le fait que ta stratégie de branching va jouer sur ta stratégie de release/déploiement. Encore une fois les furets ne suivent pas du tout ton idée et ils font autant de déploiement qu'ils le souhaitent (de tête plusieurs par semaine, un déploiement se fait en ~ 2h). D'ailleurs je ne me souviens pas d'avoir entendu Sacha Labourey (si tu veux que je cite une autre référence) parler de stratégie de branchement pour parler de continus deployment.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Workflow git

              Posté par  (site web personnel) . Évalué à 3.

              Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.

              Je suis tristesse de l'avoir mis en place plusieurs fois avec succès alors :-(

              Pour donner un peu une idée : le soft était une app mobile, multiplateforme, de pilotage de drones. On a du, plusieurs fois, réaliser de gros chantiers dans l'app tout en continuant à ajouter des features. Et quand je dis gros chantiers c'est aussi chantiers critiques, genre refonte totale de tous les checks fait avant le décollage, refonte de tout le mécanisme de détection de problème en vol. Un poil sensible.
              Et le problème c'était surtout que chacun de ses taffs dépassaient une itération de boulot. Hors on avait besoin d'avoir des versions utilisables à chaque itération.
              La solution classique c'est de faire une branche, qui va durer le temps qu'il faut, et qui sera mergée un jour. C'est hyper fatiguant. Encore plus quand, durant les refactorings un autre dev doit ajouter des features utilisant la partie refactoré (par exemple ajout d'un nouveau check avant décollage). Et il n'est pas question de le faire attendre plusieurs semaines.
              Donc tout s'est passé suivant du Branching by Abstraction. J'ai pu introduire une couche de compatibilité très rapidement, puis développer une nouvelle archi en parallèle (dans master pour simplifier un poil). Pendant un temps d'ailleurs les deux archi ont coexisté, puis tout l'existant a été converti sur la nouvelle archi, l'ancienne n'étant alors qu'une coquille vide elle a disparu. Tout c'est fait avec des branches de courtes durée (pour avoir de la review) et mergé dans master. Ainsi, alors que le boulot n'était pas fini et simplement désactivé par un ifdef, des versions utilisables était toujours présentes.
              L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence, tout le monde utilisait la nouvelle abstraction. Ce qui fait d'ailleurs que la transition old->new fut simple et avec beaucoup moins de risques que si on avait fait une branche qui avait existé pendant 3-4 semaines.

              • [^] # Re: Workflow git

                Posté par  . Évalué à 3.

                Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.

                Je suis tristesse de l'avoir mis en place plusieurs fois avec succès alors :-(

                C'est peut être mal perçu. Je suis au contraire content que ça existe. Je suis friand de retours d’expérience, même si IRL je n'ai que rarement mon mot à dire là dessus. C'est au moins pour l'esprit ;)

                L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_ ) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence, tout le monde utilisait la nouvelle abstraction.

                Dans mon monde on en est pas là (sic), on à pas d'IC sur les branches et on a pas suffisamment de tests d'intégration…

                Merci de ton retour :)

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Workflow git

                Posté par  . Évalué à 3.

                L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence,

                C'est là, je pense, qu'il y a beaucoup de confusions lors des échanges sur le sujet.

                Pour certains une "feature branch", c'est une branche locale dans laquelle on commite plusieurs fois. On la ré agence avant de pusher, on la maintient à jour avec le master avec des pull en rebase ou en merge.
                Et l'anaphore de barmic prend tout son sens: C'est un espace privé au même titre qu'un workspace SVN et pour pousser l'analogie encore plus loin, les nostalgiques de SVN peuvent se contenter de commit --amend jusqu'au moment du push. Dans mes propos, lorsque je mets en garde contre les feature branch, ce n'est pas de ça dont je parle. Au contraire, travailler dans le trunk ne dispense pas des bonnes manières à coup de rebase interactive.

                Pour d'autres (c'est à ça que je fais référence) c'est un espace partagé. C'est là que plusieurs devs pushent sur un serveur, que tournent les tests d'intégrations et que des workflows d'approbation à base de code review pre-merge se mettent en place. Ce n'est pas parce que le serveur d'intégration tourne qu'on fait de la CI (j'y reviendrai). Dans ce type d'espace, on ne peut pas se permettre des rebase en permanence par rapport à master à coup de --force car réécrire l'historique en déplaçant la ref de branche distante a des conséquences sur tous les devs, si la feature n'est pas complète. C'est pour ça qu'on passe par du merge ou par un squash (https://github.com/blog/2141-squash-your-commits).

                Un modèle intermédiaire vient avec les outils à la Github et les workflows à la « fork+pull request ». Ici on dispose d’un espace public mais exclusif. On publie sa branche sur le serveur, on peut y faire tourner la CI (détection de branche automatique), mais il reste privatif car dédié à un seul dev en écriture. Le dev recalé lors de la review peut donc republier ses modifs en soumettant sa pull request après un rebase. L’intégration est prise en charge par le serveur en automatique (squash+rebase ou merge, validation par un intégrateur, par quota de reviewer …). Ca convient pour du dev open source avec des contributeurs de tous horizons, y compris occasionnels, mais pour du dev en entreprise autour d’une équipe resserrée ça commence à devenir un peu lourd comme process, pour intégrer au fil de l’eau. En tout cas, si on passe par un intégrateur comme goulot d’étranglement, qu’on ne vienne pas me dire que c’est de la CI. On peut discuter des mérites, mais ce n’est pas de la CI (cf. plus bas). D’autres éditeurs (Atlassian) ont contourné le problème en évitant de passer par la case "fork" et en jouant sur les permissions au niveau des branches du repo central. Ca améliore le truc mais ça reste lourd. Le workflow que tu nous avais présenté dans un journal est dans la même veine même si plus léger (l'exlusivité est une pure convention) et indépendant d’une review ou d’un intégrateur.
                Mais la conséquence de tout ça, c’est que la feature est sous la conduite d’un seul gus. Niveau granularité, ça se limite donc plutôt à une task qu’une User Story (sinon repart dans le travers des long lived) et ça rend assez caduque l’argument sur l’intégration d’une US quand elle est prête.
                Concernant la CI. C’est pareil, il faut bien s’entendre sur le vocabulaire. Ce n’est pas parce que tu balances une branche sur ton serveur de CI que tu fais de la CI. Le principe de base de la CI, c’est que tout le monde intègre dans la mainline . Je vous renvoie sur un autre lien de Martin Fowler, pour savoir de quoi on cause.

                Mais bon, on s’écarte du sujet initial avec l’agilité et les feature branch. Ce qui m’a fait bondir à la base, c’est qu’on en voit toujours nous ressortir le GitFlow comme la solution à tous nos problème y compris en agilité. J’ai exposé quelques arguments pour démontrer à quel point c’est faux et que chaque projet a son contexte et que le workflow universel n’existe pas. Et je suis assez satisfait de découvrir que d’autres ont émis des réserves semblables aux miennes. Je vous invite à les lire car ça rentre bien dans les détails.

          • [^] # Re: Workflow git

            Posté par  . Évalué à 2.

            Je voudrais troller, je dirais que t'as l'air assez dogmatique dans ton agilité :)

            Juste pour être clair - tu comittes/push direct sur master? Genre plusieurs fois par jour?

            Un paramètre crucial dans le feature branch, c'est la durée de vie de la branche. Une branch qui vit 2-4 jours (sur un sprint de disons 2 semaines), c'est pas le bout du monde.
            Ton intégration continue s'en sortira, et tes merges aussi.
            Par contre, ca te permet d'avoir:

            • des codes reviews. C'est super utile, soit pour trouver un truc que l'auteur a pas vu, soit pour familiariser toute l'équipe avec toute l'appli. Je m'en sert aussi beaucoup pour passer mon expérience aux plus jeunes - un paquet de commentaires sur des trucs ok, mais qui pourrait être mieux, ou pour poser des questions sur une approche donnée (ca permet d'aborder d'autres approches)
            • des commits squashes et un historique "une feature - un commit". Quand qq chose va peter et que tu vas devoir bisecter, potentiellement sur 2-3 mois (oui, ca arrive de trouver des problèmes longtemps après le,déploiement)), t'es content de pas te taper 10 commits pour une feature, et encore moins quand lesdits commits sont entrelacés.

            Après, oui, une branche qui vit plus d'une, voire 2 semaines, faut s'attendre à des problèmes.

            Et le mec qui fait un refactoring sans demander si quelqu'un bosse sur la partie refactoree, il mérite un peu des claques, non?

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Workflow git

              Posté par  . Évalué à 3.

              Je voudrais troller, je dirais que t'as l'air assez dogmatique dans ton agilité :)

              Ce n'est vraiment pas ton genre :)

              Un paramètre crucial dans le feature branch, c'est la durée de vie de la branche. Une branch qui vit 2-4 jours (sur un sprint de disons 2 semaines), c'est pas le bout du monde.
              Ton intégration continue s'en sortira, et tes merges aussi.

              OK, plus ça dure, plus c'est dur (c'est pas comme le sexe).
              Quelle est la granularité alors ?

              Une branche par épique ? Y'en a que ça n'effraie pas et qui s'en sortir avec une un merge auto from upstream qui casse le build en CI pour forcer la mise à jour

              Au niveau de la US, elles ont parfois du mal à tenir en moins de 4 jours surtout. si comme certains le préconisent on colle juste un gus dessus. Multiplie ça par le nb de US de l'équipe et on nage en plein merge hell.

              Au niveau de la task ? Bin quel est l'intérêt d'une branche alors ? Vu que tu intègres des bouts de US, tu prends les mêmes risques de livrer une feature non finie et tu retombes dans l'effet tunnel.

              Mais tu donnes quelques éléments:

              La revue de code en amont. On n'as pas attendu les feature branch pour en faire. Mais c'est vrai que ca se fait en aval. La question mérite d'être discutée. De la revue de code en amont tu la fais au fil de l'eau lorsque tout le monde commites dans trunk. Tu fais du pair programming, … Suffit de pas puller comme un bourrin et fetcher avant de rebaser. Et le gugusse qui ne respecte pas les coding rules ou qui pète la CI, il va se faire repérer assez vite.
              Si je trollais, je dirais que ce worklow te conviens parce que t'aimes bien joué les gros bras ;-)

              Le squash pour simplifier le bisect. Si j'étais dogmatique, je dirais que ça ne devrait pas arriver souvent si t'as une batterie de tests qui te préserve de tout ça. Mais franchement 2 itérations de plus sur un bisect (surtout dans un histo linéaire), ce n’est pas le bout du monde. Et si tu bosses pas sur un UI mais sur une API, c'est encore plus simple puisque tu ne te tapes pas tout ça à la mano.
              Sinon squash or not squash, c'est un autre débat et il y en a qui sont plus favorables un histo bien découpé

              Juste pour être clair - tu comittes/push direct sur master? Genre plusieurs fois par jour?

              Indeed, mais comme je suis pragmatique.
              rebase -i obligatoire avant un push, et TU+TI mockés en local.
              une US ou 2 max à la fois pour toute l'équipe. On est en "scrum" les gars.
              Seules les US à risque ont droit à un traitement de faveur. Feature toggling et sinon une feature branch max comme ça pas d'embrouille.
              Et pis si vraiment on se ratait, les cadors git qui mergent un refactoring en 2 temps 3 mouvements adeptes du feature branch, ils sont assez frisés pour nous séparer la feature du trunk avec 2 rebase interactive et un push –force, tu ne crois pas ?

              Et le mec qui fait un refactoring sans demander si quelqu'un bosse sur la partie refactoree, il mérite un peu des claques, non?

              Y’en a encore qui osent refactorer dans ton équipe ?

      • [^] # Re: Workflow git

        Posté par  . Évalué à 4.

        Toujours pas convaincus ?

        Non ou plutôt tes arguments ne suffisent pas :)

        Ensuite, quel est le problème de livrer une feature incomplète … si elle n'affecte pas votre produit ?

        Et tu arrive à le savoir a priori ?

        Ca s'appelle le feature toggling(http://martinfowler.com/bliki/FeatureToggle.html). Vous structurez votre code pour activer ou non des fonctionnalités au déploiement (http://martinfowler.com/articles/feature-toggles.html).

        D’expérience, là où j'ai travaillé, personne n'était assez mature pour faire ça sans complètement exploser la complexité du code et sans se perdre dans toutes les fonctionnalités.

        L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu.

        Ouai bof, ça n'est pas vraiment un problème. Faut rebaser fréquemment. Sur des petites équipes ça ne pose aucun problème. Ton intégration continue elle doit surtout être toujours verte, tu dois pouvoir livrer à tout moment, à la fréquence qui te semble opportune et pas à la fréquence que tu es capable de faire. Donc non tu ne peux pas accepter qu'un gars commit une erreur ou un truc qui a un effet de bord indésiré. Si tu veux, tu peux contraindre ton IC à faire un rebase fréquent (si la branche à lancer n'est pas assez à jour la passer en erreur).

        Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment… peu avant la fin du sprint.

        Ça n'est pas une vérité générale. J'ai vu une conférence des furets. Ils n'ont pas de master et font systématiquement du big bang merge comme tu dis. Ils ont créé un outils pour ça : git-octopus.

        Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil … Fuyez !!!

        Bof. J'ai tendance à fuir celui qui me dis de fuir. Actuellement j'ai l'impression qu'on a une explosion des workflow et c'est une très bonne chose ! Les gens font ce qui marche pour eux. Ce n'est pas qu'une histoire de technique, il y a aussi de l'humain des gens qui préfèrent ou trouvent plus simple une façon plutôt qu'une autre. Je suis justement d'accord qu'il faut remettre en cause git-flow par exemple, parce que le meilleur workflow c'est celui qui convient à ton équipe. Il faut juste pas faire l'inverse et considérer que tout ce qui ne te correspond pas est nul et il faut (ça va avec) regarder ce qui se fait ailleurs pour ne pas retomber dans des pièges que d'autres ont rencontré.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.